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Prefácio 


Um de nossos doces favoritos aqui na Dinamarca é o Ga-Jol, cujos fortes vapores de licorice 
são um complemento perfeito para nosso clima úmido e, geralmente, frio. Parte do charme do 
Ga-Jol, para nós dinamarqueses, são os dizeres sábios impressos em cada caixa. Comprei dois 
pacotes dessa iguaria essa manhã e nela veio este antigo ditado dinamarquês: 

JErlighed i små ting er ikke nogen lille ting. 

"Honestidade em pequenas coisas nào é uma coisa pequena". Era um bom presságio para 
com o que eu já desejava dizer aqui. Pequenas coisas são importantes. Este é um livro sobre 
preocupações modestas cujos valores estão longe de ser pequenos. 

Deus está nos detalhes, disse o arquiteto Ludwig Mies van der Rohe. Essa citação retoma, 
argumentos com contemporâneos sobre o papel da arquitetura no desenvolvimento de software, 
especialmente no mundo Agile. Bob e eu, às vezes, acabávamos engajados entusiasmadamente 
debatendo sobre este assunto. E sim, Mies van der Rohe atentava para os utilitários e as formas 
imemoriais de construção que fundamentam uma ótima arquitetura. Por outro lado, cle também 
selecionava pessoalmente cada maçaneta para cada casa que ele projetava. Por quê? Por que 
pequenas coisas são importantes. 

Em nosso “debate” sobre Desenvolvimento dirigido a testes (TDD, sigla em inglês), Bob 
e eu descobrimos que concordamos que a arquitetura do software possuir um lugar importante 
no desenvolvimento, embora provavelmente tenhamos perspectivas diferentes do significado 
exato disso. Essas diferenças são relativamente irrelevantes contudo, pois podemos admitir que 
profissionais responsáveis dedicam algum tempo para pensar e planejar o início de um projeto. As 
noções de desenvolvimento dirigido apenas por testes e por códigos do final da década de 1990 
já não existem mais. Mesmo assim, a atenção aos detalhes é um fundamento de profissionalismo 
ainda mais crítico do que qualquer visão maior. Primeiro, é por meio da prática em pequenos 
trabalhos que profissionais adquirem proficiência e confiança para se aventurar nos maiores. 
Segundo, a menor parte de uma construção desleixada, a porta que não fecha direito ou o azulejo 
levemente torto do chão, ou mesmo uma mesa desarrumada, retiram completamente o charme 
do todo. É sobre isso que se trata o código limpo. 

Ainda assim, a arquitetura é apenas uma metáfora para o desenvolvimento de software, 
especialmente para a parte que entrega o produto inicial no mesmo sentido que um arquiteto 
entrega uma construção imaculada, Nessa época do Scrum e do Agile, o foco está em colocar o 


produto rapidamente no mercado. Desejamos que a indústria funcione em velocidade máxima 
na produção de software. Essas fábricas humanas: programadores que pensam e sentem que 
trabalham a partir das pendências de um produto ou do user story para criar o produto. A 
metáfora da fabricação está mais forte do que nunca no pensamento. Os aspectos da produção da 
manufatura japonesa de automóveis, de um mundo voltado para a linha de montagem, inspiraram 
grande parte do Scrum. 

Ainda assim, mesmo na indústria automobilística, a maior parte do trabalho não está na 
fabricação, mas na manutenção — ou na prevenção. Em software, 80% ou mais do que fazemos 
é chamado de “manutenção”: o ato de reparar. Em vez de abraçar o típico foco ocidental 
sobre a produção de bons softwares, deveríamos pensar mais como um pedreiro que conserta 
casas na indústria de construção, ou um mecânico de automóveis na área automotiva. O que o 
gerenciamento japonês tem a dizer sobre isso? 

Por volta de 1951, uma abordagem qualitativa chamada Manutenção Produtiva Total (TPM) 
surgiu no cenário japonés. Seu foco era na manutenção em vez da produção. Um dos maiores 
fundamentos da TPM é o conjunto dos chamados 5S princípios. 5S é uma série de disciplinas — uso 
aqui o termo “disciplina” para fins educativos. Os 5S princípios, na verdade, são os fundamentos 
do Lean — outro jargão no cenário ocidental, e cada vez mais conhecida no mundo dos softwares. 
Esses princípios não são uma opção. Assim como Uncle Bob diz em suas preliminares, a prática 
de um bom software requer tal disciplina: foco, presença de espírito c pensamento. Nem sempre 
é sobre fazer, sobre pressionar os equipamentos da fábrica para produzir em velocidade máxima. 
A filosofia dos 5S inclui os seguintes conceitos: 

Seiri, ou organização (pense em “ordenar”). Saber onde estão as coisas — usar abordagens 
como nomes adequados — é crucial. Acha que dar nome a identificadores não é importante? Leia 
próximos capítulos. 

Seiton, ou arrumação (pense em “sistematizar”. Há um antigo ditado americano que diz: 
“Um lugar para tudo, e tudo em seu lugar”. Um pedaço de código deve estar onde você espera 
encontrá-lo — caso não esteja, refatore e o coloque lá. 

Seiso, ou limpeza (pensem em “polir”): manter o local de trabalho livre de fios pendurados, 
gordura, migalhas e lixo. O que os autores falam aqui sobre encher seu código com comentários 
e linhas de códigos como comentários que informa o passado ou os desejos para o futuro? Livre- 
se deles. 

Seiketsu, ou padronização: a equipe concorda em manter o local de trabalho limpo. 

Você acha que este livro fala algo sobre ter um estilo de programação consistente e uma série 
de práticas dentro da equipe? De onde vêm tais padrões? Continue a leitura. 

Shutsuke, ou disciplina (autodisciplina). Isso significa ter disciplina para seguir as práticas e 
refletir frequentemente isso no trabalho e estar disposto a mudar. 

Se aceitar o desafio — isso, o desafio — de ler e aplicar o que é aconselhado neste livro, 
você entenderá e apreciará o último item. Aqui estamos finalmente indo em direção às raizes 
do profissionalismo responsável numa profissão que deve se preocupar com o ciclo de vida de 
um produto. Conforme façamos a manutenção de automóveis e outras máquinas na TPM, a 
manutenção corretiva — esperar que bugs apareçam — é a exceção. Em vez disso, subimos um 
nível: inspecionamos as máquinas todos os dias e consertamos as partes desgastadas antes de 
quebrarem, ou percorremos o equivalente aos famosos 16km antes da primeira troca de óleo para 
testar o desgaste. No código, a refatoração é impiedosa. Você ainda pode melhorar um nível a 
mais com o advento do movimento da TPM há 50 anos; construa máquinas que sejam passíveis 
de manutenção. Tornar seu código legível é tão importante quanto torná-lo executável. A última 
prática, adicionada à TPM em torno de 1960, é focar na inclusão de máquinas inteiramente novas 
ou substituir as antigas. Como nos adverte Fred Brooks, provavelmente devemos refazer partes 


principais do software a partir do zero a cada sete anos ou então se livrar dos entulhos. Talvez 
devêssemos atualizar a constante de tempo de Fred para semanas, dias ou horas, em vez de anos. 
E aí onde ficam os detalhes. 

Há um grande poder nos detalhes, mesmo assim existe algo simples e profundo sobre essa 
abordagem para a vida, como talvez esperemos de qualquer abordagem que afirme ter origem 
japonesa. Mas essa não é apenas uma visão ocidental de mundo sobre a vida; a sabedoria de 
ingleses e americanos também está cheia dessas advertências. A citação de Seiton mais acima 
veio da ponta da caneta de um ministro em Ohio que visualizou literalmente a organização 
“como um remédio para todos os níveis de mal”. 

E Seiso? Deus ama a limpeza. Por mais bonita que uma casa seja, uma mesa desarrumada 
retira seu esplendor. E Shutsuke nessas pequenas questões? Quem é fiel no pouco também é 
no muito. E que tal ficar ansioso para refatorar na hora certa, fortalecendo sua posição para 
as “grandes” decisões subsequentes, em vez de descartá-las? Um homem prevenido vale por 
dois. Deus ajuda a quem cedo madruga. Não deixe para amanhã o que se pode fazer hoje. (Esse 
era o sentido original da frase “o último momento de responsabilidade”, em Lean, até cair nas 
mãos dos consultores de software). E que tal aplicar o local de esforços pequenos e individuais 
num grande todo? De grão em grão a galinha enche o papo. Ou que tal integrar um trabalho de 
prevenção no dia a dia? Antes prevenir do que remediar. O código limpo honra as profundas 
raízes do conhecimento sob nossa cultura mais ampla, ou como ela fora um dia, ou deve ser, e 
poderá vir a ser com a atenção correta aos detalhes. 

Mesmo na grande literatura na área de arquitetura encontramos visões que remetem a esses 
supostos detalhes. Pense nas maçanetas de Mies van der Rohe. Aquilo é seiri. E ficar atento a 
cada nome de variável. Deve-se escolher o nome de uma variável com cuidado, como se fosse 
eu primeiro filho. 

Como todo proprietário de uma casa sabe, tal cuidado e constante refinamento jamais 
acaba. 

O arquiteto Christopher Alexander — pai dos padrões e das linguagens de padrões — enxerga 
cada o próprio design como um conserto pequeno e local. E ele enxerga a habilidade de uma boa 
estrutura como o único objetivo do arquiteto; pode-se deixar as formas maiores para os padrões 
e seus aplicativos para os moradores. O design é constante não só ao adicionarmos um novo 
cômodo a uma casa, mas ao nos atentarmos a repintura, a substituição de carpetes gastos ou a 
melhoria da pia da cozinha. A maioria das artes reflete relações análogas. Em nossa busca por 
outras pessoas que dizem que a casa de Deus foi feita nos mínimos detalhes, encontramo-nos em 
boa companhia do autor francês Gustav Flaubert, do século XIX. O poeta francês Paul Valery 
nos informa que um poema nunca fica pronto e requer trabalho contínuo. e parar de trabalhar 
nele seria abandoná-lo. 

Tal preocupação com os detalhes é comum a todos os encargos de excelência. Portanto, 
talvez haja pouca coisa nova aqui, mas ao ler este livro você será desafiado a retomar a disciplina 
que você há muito largou para a apatia ou um desejo pela espontaneidade e apenas “respondia 
às mudanças”. 

Infelizmente, não costumamos enxergar essas questões como peças fundamentais da arte 
de programar. Abandonamos nosso código antecipadamente, não porque ele já esteja pronto, 
mas porque nosso sistema de valores se foca mais na aparência externa do que no conteúdo que 
entregamos. 

No final, essa falta de atenção nos custa: Dinheiro ruim sempre reaparece. Pesquisas, nem no 
mercado e nem nas universidades, são humildes o bastante para se rebaixar e manter o código 
limpo. Na época em que trabalhei na empresa Bell Labs Software Production Research (produção, 
de fato!), ao ficarmos mexendo aqui e ali, nos deparamos com descobertas que sugeriam que o 


estilo consistente de endentação era um dos indicadores mais significantes estatisticamente da 
baixa incidência de bugs. 

Queríamos que a qualidade fosse produzida por essa ou aquela estrutura ou linguagem de 
programação ou outra noção de alto nível; conforme as pessoas cujo suposto profissionalismo 
se dá ao domínio de ferramentas e métodos de design grandioso, sentimo-nos ofendidos pelo 
valor que aquelas máquinas de fábricas, os codificadores, recebem devido a simples aplicação 
consistente em um estilo de endentação. Para citar meu próprio livro de 17 anos atrás, tal estilo 
faz a distinção entre excelência e mera competência. A visão de mundo japonesa entende o valor 
crucial do trabalhador diário e, além do mais, dos sistemas de desenvolvimento voltados para 
as ações simples e diárias desses trabalhadores. A qualidade é o resultado de um milhão de atos 
altruístas de importar-se — não apenas um grande método qualquer que desça dos céus. Não é 
porque esses atos são simples que eles sejam simplistas, e muito menos que sejam fáceis. Eles 
são, não obstante, a fábrica de magnitude e, também, de beleza em qualquer esforço humano. 
Ignorá-los é não ser ainda completamente humano. 

É claro que ainda defendo o conceito de um escopo mais amplo, e, especialmente, o do 

“valor de abordagens arquitetônicas arraigadas profundamente no conhecimento do dominio e de 
usabilidade do software. 

Este livro não é sobre isso — ou, pelo menos, não de modo direto. Mas ele passa uma 
mensagem mais sutil cuja essência nào deve ser subestimada. Ele se encaixa à máxima atual 
das pessoas que realmente se preocupam com o código, como Peter Sommerlad, Kevlin Henney 
e Giovanni. “O código é o projeto” e “Código simples” são seus mantras. Enquanto devamos 
tentar nos lembrar de que a interface é o programa, e que suas estruturas dizem bastante sobre a 
estrutura de nosso programa, é crucial adotar a humilde postura de que o projeto vive no código. 
E enquanto o retrabalho na metáfora da manufatura leva ao custo, o no projeto leva ao valor. 
Devemos ver nosso código como a bela articulação dos nobres esforços do projeto — projeto 
como um processo, e não uma meta estática. É no código que ocorrem as medidas estruturais 
de acoplamento e coesão. Se você vir a descrição de Larry Constantine sobre esses dois fatores, 
ele os conceitua em termos de código — e não em conceitos de alto nível como se pode encontrar 
em UML. Richard Gabriel nos informa em seu artigo Abstraction Descant que a abstração é 
maligna. O código é antimaligno, e talvez o código limpo seja divino. 

Voltando à minha pequena embalagem de Ga-Jol, acho importante notar que a sabedoria 
dinamarquesa nos aconselha a não só prestar atenção a pequenas coisas, mas também a ser 
honesto em pequenas coisas. Isso significa ser honesto com o código e tanto com nossos colegas 
e, acima de tudo, com nós mesmos sobre o estado de nosso código. Fizemos o Melhor para “deixar 
o local mais limpo do que como o encontramos”? Refatoramos nosso código antes de verificá- 
lo? Essas não são preocupações externas, mas preocupações que estão no centro dos valores 
do Agile. Que a refatoração seja parte do conceito de “Pronto”, é uma prática recomendada no 
Scrum. Nem a arquitetura e nem o código limpo exigem perfeição, apenas honestidade e que 
façamos o melhor de nós. Errar é humano; perdoar é divino. No Scrum, tornamos as coisas 
visíveis. Arejamos nossa roupa suja. Somos honestos sobre o estado de nosso código porque 
o código nunca é perfeito. Tornamo-nos mais completamente humanos, mais merecedores do 
divino e mais próximos da magnitude dos detalhes. 

Em nossa profissão. precisamos desesperadamente de toda ajuda que conseguirmos. Se o piso 
de uma loja reduz os acidentes e suas ferramentas bem organizadas aumentam a produtividade, 
então sou totalmente a favor. E relação a este livro, ele é a melhor aplicação pragmática dos 
princípios de Lean ao software que já vi. Eu não esperava nada mais deste pequeno grupo prático 
de indivíduos que se esforçaram juntos por anos não só para se aperfeiçoarem, mas também 
para presentear com seus conhecimentos o mercado com obras como esta em suas mãos agora. 


Isso deixa o mundo um pouco melhor do que quando o encontrei antes de Uncle Bob me enviar 
o manuscrito. Após ter finalizado estes exercícios com conhecimentos tão sublimes, agora vou 
limpar minha mesa. 


James O. Coplien 
Merdrup. Dinamarca 
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Que porta representa seu código? Que porta representa sua equipe ou sua companhia? 
Por que estamos naquela sala? É apenas uma revisão normal de código ou encontramos uma série 
de problemas terríveis logo após iniciarmos a apresentação? Estamos depurando em pânico, lendo 
meticulosamente um código que pensávamos que funcionava? Os clientes estão indo embora aos 
bandos e estamos com os gerentes em nossos pescoços? Como podemos garantir que cheguemos 
atrás da porta certa quando o caminho fica difícil? A resposta é: habilidade profissional. 

Há duas vertentes para se obter habilidade profissional: conhecimento e trabalho. Você deve 
adquirir o conhecimento dos princípios, padrões, práticas e heurísticas que um profissional 


habilidoso sabe, e também esmiuçar esse conhecimento com seus dedos, olhos e corpo por meio 
do trabalho árduo e da prática. 

Posso lhe ensinar a mecânica para se andar de bicicleta. Na verdade, a matemática clássica 
é relativamente direta. Gravidade, atrito, momento angular, centro de massa, e assim por diante, 
podem ser demonstrados com menos de uma página cheia de equações. Dada essas fórmulas, 
eu poderia provar para você que é prático andar de bicicleta e lhe dar todo o conhecimento 
necessário para que você consiga. E mesmo assim você cairá na primeira vez que tentar. 

Programar não é diferente. Poderíamos pôr no papel todos os princípios necessários para um 
código limpo e, então, confiar que você fará as tarefas (isto é. deixar você cair quando subir na 
bicicleta), mas que tipo de professores e de estudantes isso faria de nós? 

Não. Essa não é a forma que este livro seguirá. 

Aprender a criar códigos limpos é uma tarefa árdua e requer mais do que o simples 
conhecimento dos princípios e padrões. Você deve suar a camisa: praticar sozinho e ver que 
cometeu erros; assistir a outros praticarem e errarem; vê-los tropeçar e refazer seus passos; Vê- 
los agonizar para tomar decisões e o preço que pagarão por as terem tomado da maneira errada. 

Esteja preparado para trabalhar duro enquanto ler este livro. Esse não é um livro fácil e 
simples que você pode ler num avião e terminar antes de aterrissar. Este livro lhe fará trabalhar, 
e trabalhar duro. Que tipo de trabalho você fará? Você lerá códigos aqui, muitos códigos. 

E você deverá descobrir o que está correto e errado nos códigos. Você terá de seguir o 
raciocínio conforme dividirmos módulos e os unirmos novamente. Isso levará tempo e esforço, 
mas achamos que valerá a pena. 

Dividimos este livro em três partes. Na primeira há diversos capítulos que descrevem os 
princípios, padrões e práticas para criar um código limpo. Há um tanto de códigos nessa parte, e 
será desafiador lê-los. Eles lhe prepararão para a seção seguinte. Se você deixar o livro de lado 
após essa primeira parte. Bem. boa sorte! 

Na segunda parte entra o trabalho pesado que consiste em diversos estudos de caso de 
complexidade cada vez maior. Cada um é um exercício para limpar um código — resolver alguns 
problemas dele. O detalhamento nesta seção é intenso. Você terá de ir e voltar por entre as folhas 
de textos e códigos, e analisar e entender o código com o qual estamos trabalhando e captar nosso 
raciocínio para cada alteração que fizermos. Reserve um tempo para essa parte, pois deverá levar 
dias. 

A terceira parte é a compensação. É um único capítulo com uma lista de heurísticas e “odores” 
reunidos durante a criação dos estudos de caso. Conforme progredirmos e limparmos os códigos 
nos estudos de caso, documentaremos cada motivo para nossas ações como uma heurística ou um 
“odor”. Tentaremos entender nossas próprias reações em relação ao código quando estivermos 
lendo ou alterando-o, e trabalharemos duro para captar por que nos sentimos de tal forma e por 
que fizemos isso ou aquilo. O resultado será um conhecimento base que descreve a forma como 
pensamos quando criamos, lemos e limpamos um código. 

Este conhecimento base possui um valor limitado se você não ler com atenção ao longo dos 
casos de estudo na segunda parte deste livro. Neles, anotamos cuidadosamente cada alteração 
que fizemos com referências posteriores às heuristicas. Tais referências aparecem em colchetes, 
assim: [H22]. Isso lhe permite ver o contexto no qual são aplicadas e escritas aquelas heurísticas! 
Essas, em si, não são tão valiosas, mas, sim, a relação entre elas e as diferentes decisões que 
tomamos ao limpar o código nos casos de estudo. 

A fim de lhe ajudar ainda mais com essas relações, colocamos no final do livro uma referência 
cruzada que mostra o número da página para cada referência. Você pode usá-la com um guia 
rápido de consulta para saber onde uma determinada heurística foi aplicada. 

Mesmo se você ler a primeira e a terceira seções e pular para os casos de estudo, ainda 


assim terá lido um livro que satisfaz sobre a criação de um bom software. Mas se não tiver 
pressa e explorar os casos de estudo, seguindo cada pequeno passo e cada minuto de decisão, se 
colocando em nosso lugar e se forçando a seguir a mesma linha de raciocínio que usamos, então 
você adquiriu um entendimento muito mais rico de todos aqueles princípios, padrões, práticas 
e heurísticas. Todo esse conhecimento ficará em cada fibra de seu corpo. Ele se tornará parte de 
você da mesma forma que ao aprender a andar de bicicleta, cla se torna uma parte de sua vontade 


de pedalá-la. 
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Sobre a capa 


A imagem da capa se é a M104 — a Galáxia Sombrero —, que fica na constelação de Virgem 
e está a pouco menos de 30 milhões de anos-luz de nós. Em seu centro há um buraco negro 
supermassivo cujo peso equivale um bilhão de vezes a massa do sol. 

A imagem lhe faz lembrar da explosão da lua Praxis, de Klingon? Eu me recordo vividamente 
a cena de Jornada nas Estrelas VI que mostrava um anel equatorial de destroços voando devido à 
explosão. Desde essa cena, o anel equatorial se tornou um componente comum explosões em 
filmes de ficção cientifica. Ele até foi adicionado à explosão de Alderaan nas últimas versões do 
filme Jornada nas Estrelas. 

O que causou a formação desse anel em torno de M104? Por que ele possui um bojo tão 
amplo e um núcleo tão minúsculo e brilhoso? Parece-me como se o buraco negro central perdeu 
sua graça e lançou um buraco de 30.000 anos-luz no meio da galáxia, devastando quaisquer 
civilizações que estivessem no caminho daquele distúrbio cósmico. 

Buracos negros supermassivos engolem estrelas inteiras no almoço, convertendo uma 
considerável fração de sua massa em energia. E = MC2 já 
é bastante potência, mas quando M é uma massa estelar: 

Cuidado! Quantas estrelas caíram impetuosamente 
naquelas presas antes de o monstro ficar saciado? 

O tamanho do vào central poderia ser uma dica' 

A imagem de M104 da capa é uma combinação da 
famosa fotografia de luz visível do Hubble (foto superior) 
com a recente imagem infravermelha do observatório 
espacial Spitzer (foto inferior). E essa segunda imagem 
que nos mostra claramente a natureza do anel da galáxia. 
Na luz visível, vemos apenas a extremidade frontal do anel 
como uma silhueta. O bojo central ofusca o resto do anel. 

Mas no infravermelho, as partículas “quentes” — isto 
é, altamente radioativas — no anel brilham através do bojo 
central. A combinação de ambas as imagens nos mostra 
uma visão que não havíamos visto antes e indica que, há 
muito tempo atrás, lá havia um inferno enfurecido de atividades. 
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Código Limpo 


Há duas razões pelas quais você está lendo este livro: você é programador е deseja se tornar um 
ainda melhor. Ótimo. Precisamos de programadores melhores. 


2 Capítulo 1: Código Limpo 


Este livro fala sobre programação e está repleto de códigos que examinaremos a partir 
de diferentes perspectivas: de baixo para cima, de cima para baixo e de dentro para fora. Ao 
terminarmos, teremos um amplo conhecimento sobre códigos e seremos capazes de distinguir 
entre um código bom e um código ruim. Saberemos como escrever um bom código e como 
tornar um ruim em um bom. 


O Código 


Podem dizer que um livro sobre códigos é, de certa forma, algo ultrapassado, que a 
programação deixou de ser uma preocupação e que devemos nos preocupar com modelos 
e requisitos. Outros até mesmo alegam que o fim do código, ou seja, da programação, está 
próximo: que logo todo código será gerado, e não mais escrito. E que não precisarão mais de 
programadores. pois as pessoas criarão programas a partir de especificações. 

Bobagens! Nunca nos livraremos dos códigos, pois eles representam os detalhes dos 
requisitos. Em certo nível, não há como ignorar ou abstrair esses detalhes; eles precisam 
ser especificados. E especificar requisitos detalhadamente de modo que uma máquina possa 
executá-los é programar — e tal especificação é o código. 

Espero que o nível de de nossas linguagens continue a aumentar e que o número de 
linguagens específicas a um domínio continue crescendo. Isso será bom, mas não acabará com 
a programação. De fato, todas as especificações escritas nessas linguagens de níveis mais altos 
e específicas a um domínio serão códigos! Eles precisarão ser minuciosos, exatos e bastante 
formais e detalhados para que uma máquina possa entendê-los e executá-los. 

As pessoas que pensam que o código um dia desaparecerá são como matemáticos que 
esperam algum dia descobrir uma matemática que não precise ser formal. Elas esperam que 
um dia descubramos uma forma de criar máquinas que possam fazer o que desejamos em vez 
do que mandamos. Tais máquinas terão de ser capazes de nos entender tão bem de modo que 
possam traduzir exigências vagamente especificadas em programas executáveis perfeitos para 
satisfazer nossas necessidades. 

Isso jamais acontecerá. Nem mesmo os seres humanos, com toda sua intuição e criatividade, 
têm sido capazes de criar sistemas bem-sucedidos a partir das carências confusas de seus 
clientes. Na verdade, se a matéria sobre especificação de requisitos não nos ensinou nada, é 
porque os requisitos bem especificados são tão formais quanto os códigos e podem agir como 
testes executáveis de tais códigos! 

Lembre-se de que o código é a linguagem na qual expressamos nossos requisitos. Podemos 
criar linguagens que sejam mais próximas a eles. Podemos criar ferramentas que nos ajudem 
a analisar a sintaxe e unir tais requisitos em estruturas formais. Mas jamais eliminaremos a 
precisão necessária — portanto, sempre haverá um código. 


Código Ruim Я 


Código ruim 


Recentemente li o prefácio do livro Implementation 
Patterns! de Kent Beck, no qual ele diz “... este livro 
baseia-se numa premissa frágil de que um bom código 
importa...". Uma premissa frágil? Não concordo! Acho 
que essa premissa é uma das mais robustas, apoiadas 
e plenas do que todas as outras em nossa área (e sei 
que Kent sabe disso). Estamos cientes de que um bom 
código importa, pois tivemos de lidar com a falta dele 
por muito tempo. 

Lembro que no final da década de 1980 uma empresa 
criou um aplicativo extraordinário que se tornou muito. 
popular e muitos profissionais o compraram e usaram. 
Mas, então, o intervalo entre os lançamentos das novas 
distribuições começou a aumentar. Os bugs não eram 
consertados na distribuição seguinte. E o tempo de 
carregamento do aplicativo e o número de travamentos 
aumentaram. Lembro-me do dia em que, frustrado, 
fechei o programa e nunca mais o usei. A empresa saiu 
do mercado logo depois. 

Duas décadas depois encontrei um dos funcionários de tal empresa na época e o perguntei o 
que havia acontecido, e o que eu temia fora confirmado. Eles tiveram de apressar o lançamento 
do produto e, devido a isso, o código ficou uma zona. Então, conforme foram adicionando mais 
e mais recursos, o código piorava cada vez mais até que simplesmente não era mais possível 
gerenciá-lo. Foi o código ruim que acabou com a empresa. 

Alguma vez um código ruim já lhe atrasou consideravelmente? Se você for um programador. 
independente de sua experiência, então já se deparou várias vezes com esse obstáculo. Aliás, é 
como se caminhássemos penosamente por um lamacal de arbustos emaranhados com armadilhas 
ocultas.Isso é о que fazemos num código ruim. Pelejamos para encontrar nosso caminho. 
esperando avistar alguma dica. alguma indicação do que está acontecendo; mas tudo o que 
vemos é um código cada vez mais sem sentido. 

É claro que um código ruim já lhe atrasou. Mas, então, por que você o escreveu dessa forma? 
Estava tentando ser rápido? Estava com pressa? Provavelmente. Talvez você pensou que não 
tivesse tempo para fazer um bom trabalho; que seu chefe ficaria com raiva se você demorasse 
um pouco mais para limpar seu código. Talvez você estava apenas cansado de trabalhar neste 
programa e queria terminá-lo logo. Ou verificou a lista de coisas que havia prometido fazer e 
percebeu que precisava finalizar este módulo de uma vez, de modo que pudesse passar para o 
próximo. Todos já fizemos isso, já vimos a bagunça que fizemos e, então, optamos por arrumá- 
las outro dia. Todos já nos sentimos aliviados ao vermos nosso programa confuso funcionar e 
decidimos que uma bagunça que funciona é melhor do que nada. Todos nós já dissemos que 
revisaríamos e limparíamos o código depois. É claro que naquela época não conhecíamos a lei 
de LeBlanc: Nunca é tarde. 


1. [Beck07]. 
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O Custo de Ter um Código Confuso 


Se você é programador a mais de dois ou três anos, provavelmente o código confuso de outra 
pessoa já fez com que você trabalhasse mais lentamente e provavelmente seu próprio código já 
lhe trouxe problemas. 

O nível de retardo pode ser significativo. Ao longo de um ou dois anos, as equipes que 
trabalharam rapidamente no início de um projeto podem perceber mais tarde que estão indo a 
passos de tartaruga. Cada alteração feita no código causa uma falha em outras duas ou três partes 
do mesmo código. Mudança alguma é trivial. Cada adição ou modificação ao sistema exige 
que restaurações, amarrações e remendos sejam “entendidas” de modo que outras possam ser 
incluídas. Com o tempo, a bagunça se torna tão grande e profunda que não dá para arrumá-la. 
Não há absolutamente solução alguma. 

Conforme a confusão aumenta, a produtividade da equipe diminui, assintoticamente 
aproximando-se de zero. Com a redução da produtividade, a gerência faz a única coisa que ela 
pode; adiciona mais membros ao projeto na esperança de aumentar a produtividade. Mas esses 
novos membros não conhecem o projeto do sistema, não sabem a diferença entre uma mudança 
que altera o propósito do projeto e aquela que o atrapalha. Ademais, eles, e todo o resto da 
equipe. estão sobre tremenda pressão para aumentar a produtividade. Com isso todos criam mais 
e mais confusões, levando a produtividade mais perto ainda de zero (veja a Figura 1.1). 


Time 


Figura 1.1 
Produtividade v. tempo 
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O Grande Replanejamento 


No final, a equipe se rebela. Todos informam à gerência que não conseguem mais trabalhar neste 
irritante código-fonte e exigem um replanejamento do projeto. Apesar de a gerência não querer 
gastar recursos em uma nova remodelação, ela não pode negar que a produtividade está péssima. 
No final das contas, ela acaba cedendo às exigências dos desenvolvedores e autoriza o grande 
replanejamento desejado. 

É, então, formada uma nova equipe especializada. Por ser um projeto inteiramente novo, 
todos querem fazer parte dessa equipe. Eles desejam começar do zero e criar algo belo de verdade. 
Mas apenas os melhores e mais brilhantes são selecionados e os outros deverão continuar na 
manutenção do sistema atual. 

Agora ambos os times estão numa corrida. A nova equipe precisa construir um novo sistema 
que faça o mesmo que o antigo, além de ter de se manter atualizada em relação às mudanças 
feitas constantemente no sistema antigo. Este, a gerência não substituirá até que o novo possa 
fazer tudo também. 

Essa corrida pode durar um bom tempo. Já vi umas levarem 10 anos. E, quando ela termina, 
os membros originais da nova equipe já foram embora há muito tempo, e os atuais exigem o 
replancjamento de um novo sistema, pois está tudo uma zona novamente. 

Se você já vivenciou pelo menos um pouco dessa situação, então sabe que dedicar 
tempo para limpar seu código não é apenas eficaz em termos de custo, mas uma questão de 
sobrevivência profissional. 


Atitude 

Você já teve de trabalhar penosamente por uma confusão tão grave que levou semanas o que 
deveria ter levado horas? Você já presenciou o que deveria ser uma alteração única e direta, mas 
que em vez disso foi feita em diversos módulos distintos? Todos esses sintomas são bastante 
comuns. 

Por que isso ocorre em um código? Por que um código bom se decompõe tão rápido em 
um ruim? Temos diversas explicações para isso. Reclamamos que os requisitos mudaram de 
tal forma que estragaram o projeto original. Criticamos os prazos por serem curtos demais para 
fazermos as coisas certas. Resmungamos sobre gerentes tolos e clientes intolerantes e tipos de 
marketing inúteis e técnicos de telefone. Mas o padrão, querido Dilbert”, não está em nossas 
estrelas, mas sim em nós mesmos. Somos profissionais. 

Isso pode ser algo difícil de engolir. Mas como poderia essa zona ser nossa culpa? E os 
requisitos? E o prazo? E os tolos gerentes e tipos de marketing inúteis? Eles não carregam 
alguma parcela da culpa? 

Não. Os gerentes e marketeiros buscam em nós as informações que precisam para fazer promessas 
e firmarem compromissos; e mesmo quando não nos procuram, não devemos dar uma de tímidos ao 
dizer-lhes nossa opinião. Os usuários esperam que validemos as maneiras pelas quais os requisitos se 
encaixarão no sistema. Os gerentes esperam que os ajudemos a cumprir o prazo. Nossa cumplicidade 
no planejamento do projeto é tamanha que compartilhamos de uma grande parcela da responsabilidade 
em caso de falhas; especialmente se estas forem em relação a um código ruim. 
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“Mas, espere!”, você diz. “E se eu não fizer o que meu gerente quer, serei demitido”. É 
provável que não. 

A maioria dos gerentes quer a verdade, mesmo que demonstrem o contrário. A maioria deles 
quer um código bom, mesmo estourando o prazo. Eles podem proteger com paixão o prazo e os 
requisitos, mas essa é a função deles. A sua é proteger o código com essa mesma paixão. 

Para finalizar essa questão, e se você fosse médico e um paciente exigisse que você parasse 
com toda aquela lavação das mãos na preparação para a cirurgia só porque isso leva muito tempo?” 
É óbvio que o chefe neste caso é o paciente; mas, mesmo assim. o médico deverá totalmente se 
recusar obedecê-lo. Por quê? Porque o médico sabe mais do que o paciente sobre os riscos de 
doenças e infecções. Não seria profissional (sem mencionar criminoso) que o médico obedecesse 
ao paciente neste cenário. Da mesma forma que não é profissional que programadores cedam à 
vontade dos gerentes que não entendem os riscos de se gerar códigos confusos. 


O Principal Dilema 


Os programadores se deparam com um dilema de valores básicos. Todos os desenvolvedores 
com alguns anos a mais de experiência sabem que bagunças antigas reduzem o rendimento. 
Mesmo assim todos eles se sentem pressionados a cometer essas bagunças para cumprir os 
prazos. Resumindo, eles não se esforçam para. 

Os profissionais sérios sabem que a segunda parte do dilema está errada, Você não cumprirá 
o prazo se fizer bagunça no código. De fato, tal desorganização reduzirá instantaneamente sua 
velocidade de trabalho, e você perderá o prazo. А única maneira de isso não acontecer — a única 
maneira de ir mais rápido — é sempre manter o código limpo. 


A Arte do Código Limpo? 


Digamos que você acredite que um código confuso seja um obstáculo relevante. Digamos que 
você aceite que a única forma de trabalhar mais rápido é manter seu código limpo. Então, você 
deve se perguntar: “Como escrever um código limpo?” Não vale de nada tentar escrever um 
código limpo se você não souber o que isso significa. 

As más notícias são que escrever um código limpo é como pintar um quadro. A maioria de 
nós sabe quando a figura foi bem ou mal pintada. Mas ser capaz de distinguir uma boa arte de 
uma ruim não significa que você saiba pintar. Assim como saber distinguir um código limpo de 
um ruim não quer dizer que saibamos escrever um código limpo. 

Escrever um código limpo exige o uso disciplinado de uma miríade de pequenas técnicas 
aplicadas por meio de uma sensibilidade meticulosamente adquirida sobre “limpeza”. A 
“sensibilidade ao código” é o segredo. Alguns de nós já nascemos com ela. Outros precisam se 
esforçar para adquiri-la. Ela não só nos permite perceber se o código é bom ou ruim, como também 
nos mostra a estratégia e disciplina de como transformar um código ruim em um limpo. 

Um programador sem “sensibilidade ao código” pode visualizar um módulo confuso e 
reconhecer a bagunça, mas não saberá o que fazer a respeito dela. Já um com essa sensibilidade 
olhará um módulo confuso e verá alternativas. A “sensibilidade ao código” ajudará a esse 


> Em 1847. quando Ignaz Semmelweis sugeriu pela primeira vez a lavagem das mãos, ela foi rejeitada. baseando-se no fato de que os médicos cram ocupados 
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programador a escolher a melhor alternativa e o orientará na criação de uma sequência de 
comportamentos para proteger as alterações feitas aqui e ali. 

Em suma, um programador que escreve um código limpo é um artista que pode pegar 
uma tela em branco e submetê-la a uma série de transformações até que se torne um sistema 
graciosamente programado. 


O que é um Código Limpo? 


Provavelmente existem tantas definições como existem programadores. Portanto, perguntei a 
alguns programadores bem conhecidos e com muita experiência o que achavam. 


Bjarne Stroustrup, criador do C++ 
e autor do livro A linguagem de 
programação C++ 


Gosto do meu código elegante e eficiente. A lógica 
deve ser direta para dificultar o encobrimento de bugs. 
as dependências minimas para facilitar a manutenção, 
o tratamento de erro completo de acordo com uma 
estratégia clara е o desempenho próximo do mais 
eficiente de modo a não incitar as pessoas a tornarem o 
código confuso com otimizacóes sorrateiras. O código 
limpo faz bem apenas uma coisa. 


Bjame usa a palavra “elegante” — uma 
palavra e tanto! O dicionário possui as seguintes 
definições: que se caracteriza pela naturalidade 
de harmonia, leveza, simplicidade; naturalidade 
no modo se dispor; requintado, fino, estiloso. 
Observe a ênfase dada à palavra “naturalidade”. 
Aparentemente, Bjarne acha que um código limpo proporciona uma leitura natural; e lê-lo deve 
ser belo como ouvir uma música num rádio ou visualizar um carro de design magnífico. 

Bjarne também menciona duas vezes “eficiência”. Talvez isso não devesse nos surpreender 
vindo do criador do C++, mas acho que ele quis dizer mais do que um simples desejo por 
agilidade. A repetição de ciclos não é elegante, não é belo. E repare que Bjarne usa a palavra 
“incitar” para descrever a consequência de tal deselegáncia. A verdade aqui é que um código 
ruim incita o crescimento do caos num código. Quando outras pessoas alteram um código ruim, 
elas tendem a piorá-lo. 

Pragmáticos, Dave Thomas e Andy Hunt expressam isso de outra forma. Eles usam a metáfora 
das janelas quebradas.? Uma construção com janelas quebradas parece que ninguém cuida dela. 
Dessa forma, outras pessoas deixam de se preocupar com ela também. Elas permitem que as 
outras janelas se quebrem também. No final das contas, as próprias pessoas as quebram. Elas 
estragam a fachada com pichações e deixam acumular lixo. Uma única janela inicia o processo 
de degradação. 


pirar сырйо dram comi bookselleni/2004- 12: bend 


8 Capítulo 1: Código Limpo 


Bjarne também menciona que o tratamento de erro deva ser completo. Isso significa prestar 
atenção nos detalhes. Um tratamento de erro reduzido é apenas uma das maneiras pela qual 
os programadores deixam de notar os detalhes. Perdas de memória e condições de corrida são 
outras. Nomenclaturas inconsistentes são ainda outras. A conclusão é que um código limpo 
requer bastante atenção aos detalhes. 

Bjarne conclui com a asseveração de que um código limpo faz bem apenas uma coisa. Não é 
por acaso que há inúmeros princípios de desenvolvimento de software que podem ser resumidos 
a essa simples afirmação. Vários escritores já tentaram passar essa ideia. Um código ruim 
tenta fazer coisas demais, ele está cheio de propósitos obscuros e ambíguos. O código limpo é 
centralizado. Cada função, cada classe, cada módulo expõe uma única tarefa que nunca sofre 
interferência de outros detalhes ou fica rodeada por cles. 


Grady Booch, autor do livro Object 
Oriented Analysis and Design with 
Applications 


Um código limpo é simples e direto. Ele é tão bem legível 
quanto uma prosa bem escrita. Ele jamais torna confuso o 
objetivo do desenvolvedor, em vez disso, ele está repleto de 


abstrações claras e linhas de controle objetivas. 


Grady fala de alguns dos mesmos pontos que Bjarne, 
voltando-se mais para questão da legibilidade. Eu, 
particularmente, gosto desse ponto de vista de que ler um 
código limpo deve ser como ler uma prosa bem escrita. 
Pense num livro muito bom que você já leu. Lembre-se de como as palavras eram substituídas 
por imagens! Era como assistir a um filme, não era? Melhor ainda, você via os personagens, 
ouvia os sons, envolvia-se nas emoções e no humor. 

Ler um código limpo jamais será como ler O senhor dos anéis. Mesmo assim, a analogia 
com a literatura não é ruim. Como um bom romance, um código limpo deve expor claramente 
as questões do problema a ser solucionado. Ele deve desenvolvê-las até um clímax e, então. dar 
ao leitor aquele “Ahá! Mas é claro!”, como as questões e os suspenses que são solucionados na 
revelação de uma solução óbvia. 

Acho que o uso que Grady faz da frase “abstrações claras” é um paradoxo fascinante! 
Apesar de tudo, a palavra “clara” é praticamente um sinônimo para “explícito”. Meu dicionário 
MacBook tem a seguinte definição para "claro(a)": direto, decisivo, sem devaneios ou detalhes 
desnecessários. Apesar desta justaposição de significados, as palavras carregam uma mensagem 
poderosa. Nosso código deve ser decisivo, sem especulações. Ele deve conter apenas o necessário. 
Nossos leitores devem assumir que fomos decisivos. 
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O “grande” Dave Thomas, fundador da 
OTI, o pai da estratégia Eclipse 


Além de seu criador, um desenvolvedor pode ler e melhorar 
um código limpo. Ele tem testes de unidade e de aceitação, 
nomes significativos; ele oferece apenas uma maneira. e não 
várias, de se fazer uma tarefa; possui poucas dependências, 
as quais são explicitamente declaradas e oferecem um 
API mínimo e claro. O código deve ser inteligível já que 
dependendo da linguagem, nem toda informação necessária 
pode expressa no código em si. 


Dave compartilha do mesmo desejo de Grady pela 
legibilidade, mas com uma diferença relevante. Dave 
afirma que um código limpo facilita para que outras 
pessoas o melhorem. Pode parecer óbvio, mas não se deve 
enfatizar muito isso. На, afinal de contas, uma diferença 
entre um código fácil de ler e um fácil de alterar. 

Dave associa limpeza a testes! Dez anos atrás, isso levantaria um ar de desconfiança. Mas o 
estudo do Desenvolvimento Dirigido a Testes teve grande impacto em nossa indústria e se tornou 
uma de nossos campos de estudo mais essenciais. Dave está certo. Um código, sem testes, não 
está limpo. Não importa o quão elegante, legível ou acessível esteja que, se ele não possuir testes, 
ele não é limpo. 

Dave usa a palavra mínima duas vezes. Aparentemente ele dá preferência a um código 
pequeno. De fato, esse tem sido uma citação comum na literatura computacional. Quando menor. 
melhor. Dave também diz que o código deve ser inteligível — referência esta à programação 
inteligível" (do livro Literate Programming) de Donald Knuth. A conclusão é que o código deve j 
ser escrito de uma forma que seja inteligivel aos seres humanos. 


Michael Feathers, autor de Working 
Effectively with Legacy Code 


Eu poderia listar todas as qualidades que vejo em um código 
limpo, mas há uma predominante que leva a todas as outras. 

Um código limpo sempre parece que foi escrito por alguém 
que se importava. Não há nada de óbvio no que se pode fazer 
para torná-lo melhor. Tudo foi pensado pelo autor do código, 
e se tentar pensar em algumas melhoras, você voltará ao 
início, ou seja, apreciando o código deixado para você por 


alguém que se importa bastante com essa tarefa. 


One word: care. É esse o assunto deste livro. Talvez 
um subtítulo apropriado seria Como se importar 
com o código. 

Michael bate na testa: um código limpo é um código 
que foi cuidado por alguém. Alguém que calmamente 
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o manteve simples e organizado; alguém que prestou a atenção necessária aos detalhes; alguém 
que se importou. 


Ron Jeffries, autor de Extreme 
Programming Installed and Extreme 
Programming Adventures in Cit 


Ron iniciou sua carreira de programador em Fortran, no 
Strategic Air Command, e criou códigos em quase todas 
as linguagens e máquinas. Vale a pena considerar suas 
palavras: 


Nestes anos recentes, comecei, e quase finalizei, com as regras 
de Beck sobre código simples. Em ordem de prioridade, são: 


ее todos os testes: 

+ Sem duplicação de código; 

+ Expressa todas as ideias do projeto que estão no sistema; 

+ Minimiza o número de entidades, como classes, métodos, 
funções e outras do tipo. 


Dessas quatro, foco-me mais na de duplicação. Quando a mesma coisa é feita repetidas vezes, é sinal de que 
ита ideia em sua cabeça não está bem representada no código. Tento descobrir o que é e, então, expressar 
aquela ideia com mais clareza. 

Expressividade para mim são nomes significativos e costume mudar o nome das coisas várias vezes antes de 
finalizar. Com ferramentas de programação modernas, como a Eclipse, renomear é bastante fácil, e por isso 
“não me incomodo em fazer isso. Entretanto, a expressividade vai além de nomes. Também verifico se um método 
ои objeto faz mais de uma tarefa. Se for um objeto, provavelmente ele precisará ser dividido em dois ou mais. Se 
for um método, sempre uso a refatoração do Método de Extração nele, resultando em um método que expressa 
mais claramente sua função e em outros métodos que dizem como ela é feita. 

Duplicação e expressividade me levam ao que considero um código limpo. e melhorar um código ruim com 
apenas esses dois conceitos na mente pode fazer uma grande diferença. Há, porém, uma outra coisa da qual 
estou ciente quando programo, que é um pouco mais dificil de explicar. 

Após anos de trabalho, parece-me que todos os programadores pensam tudo igual. Um exemplo é “encontrar 
coisas numa coleção”. Tenhamos uma base de dados com registros de funcionários ou uma tabela hash de 
chaves e valores ou um vetor de itens de algum tipo, geralmente procuramos um item específico naquela 
coleção. Quando percebo isso, costumo implementar essa função em um método ou classe mais abstrato — o 
que me proporciona algumas vantagens interessantes. 

Posso implementar a funcionalidade agora com algo mais simples, digamos uma tabela hash, mas como agora 
todas as referências àquela busca estão na minha classe ou método abstrato, posso alterar a implementação 
sempre que desejar. Posso ainda prosseguir rapidamente enquanto preservo a capacidade de alteração 
futura. 

“Além disso, a de coleções geralmente chama minha atenção para o que realmente está acontecendo, e impede 
que eu implemente funcionalidades arbitrárias em coleções quando tudo que eu preciso são simples maneiras de 
encontrar o que desejo. Redução de duplicação de código, alta expressividade e criação no início de abstrações 
simples. É isso que torna para mim um código limpo. 


Aqui, em alguns breves parágrafos, Ron resumiu o conteúdo deste livro. Sem duplicação, uma 
tarefa, expressividade, pequenas abstrações. Tudo foi mencionado. 


O Custo de Ter um Código Confuso п 


Ward Cunningham, criador do conceito 
de “WikiWiki”, criador do Fit, co-criador 
da Programação Extrema (eXtreme 
Programming). Incentivador dos Padrões 
de Projeto. Líder da Smalltalk e da OO. 
Pai de todos aqueles que se importam 
com o código. 


Você sabe que está criando um código limpo quando cada rotina 
que você leia se mostra como o que você esperava. Você pode 
chamar de código belo quando ele também faz parecer que a 


linguagem foi feita para o problema. 


Declarações como essa são características de Ward. Você a 

lé, coloca na sua cabeça e segue para a próxima. Parece tão racional, tão óbvio que raramente é 
memorizada como algo profundo. Você acha que basicamente já pensava assim. Mas observemos 
mais atentamente. 

<... O que você esperava”. Qual foi a última vez que você viu um módulo como você o 
esperava que fosse? Não é mais comum eles serem complexos, complicados, emaranhados? 
Interpretá-lo erroneamente não é a regra? Você não está acostumado a se descontrolar ao tentar 
entender o raciocínio que gerou todo o sistema e associá-lo ao módulo que estás lendo? Quando 
foi a última vez que você leu um código para o qual você assentiu com a cabeça da mesma forma 
que fez com a declaração de Ward? 

Este espera que ao ler um código limpo nada lhe surpreenda. De fato, não será nem preciso 
muito esforço. Você irá lê-lo e será basicamente o que você já esperava. O código é óbvio,” 
simples e convincente. Cada módulo prepara o terreno para o seguinte. Cada um lhe diz como o 
próximo estará escrito. Os programas que são tão limpos e claros assim foram tão bem escritos 
que você nem perceberá. O programador o faz parecer super simples, como o é todo projeto 
extraordinário. 

E a noção de beleza do Ward? Todos já reclamamos do fato de nossas linguagens não tiverem 
sido desenvolvidas para os nossos problemas. Mas a declaração de Ward coloca novamente 
o peso sobre nós. Ele diz que um código belo faz parecer que a linguagem foi feita para o 
problema! Portanto, é nossa responsabilidade fazer a linguagem parecer simples! Há brigas 
por causa das linguagens em todo lugar, cuidado! Não é a linguagem que faz os programas 
parecerem simples, é o programador! 
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Escolas de Pensamento 


E eu (Tio Bob)? O que é um código limpo para mim? É 
isso o que este livro lhe dirá em detalhes, o que eu e meus 
compatriotas consideramos um código limpo. Diremo-lhe o 
que consideramos como nomes limpos de variáveis, funções 
limpas, classes limpas etc. Apresentaremos nossos conceitos 
como verdades absolutas, e não nos desculparemos por nossa 
austeridade. Para nós, a essa altura de nossa carreira, tais 
conceitos são absolutos. São nossa escola de pensamento 
acerca do que seja um código limpo. 

Nem todos os mestres de artes marciais concordam 
com qual seria a melhor arte marcial de todas ou a melhor 
técnica dentro de uma arte marcial específica. Geralmente, 
eles criam suas próprias escolas de pensamento e recrutam 
alunos para serem ensinados. Dessa forma, temos o Jiu 
Jitsu dos Gracie, criado e ensinado pela família Gracie, no Brasil; o Jiu Jitsu de Hakkoryu, 
criado e ensinado por Okuyama Ryuho, em Tóquio; e o Jeet Kune Do, criado e ensinado por 
Bruce Lee, nos EUA. 

Os estudantes se dedicam à doutrina ensinada por aquela determinada arte, e aprendem o 
que seus mestres ensinam, geralmente ignorando os ensinamentos de outros mestres. Depois, 
conforme os estudantes progridem, costuma-se mudar o mestre de modo que possam expandir 
seus conhecimentos e práticas. Alguns, no final, continuam a fim de refinar suas habilidades, 
descobrem novas técnicas e criam suas próprias escolas. 

Nenhuma dessas escolas está 100% certa. Mesmo assim dentro de uma determinada escola 
agimos como os ensinamentos e técnicas fossem os certos. Apesar de tudo, há uma forma correta 
de praticar o Jiu Jitsu de Hakkoryu, ou Jeet Kune Do. Mas essa retidão dentro de uma escola não 
invalida as técnicas de outra. 

Considere este livro como uma descrição da Escola de Código Limpo da Object Mentor. As 
técnicas e ensinamentos são a maneira pela qual praticamos nossa arte. Estamos dispostos a alegar 
que se você seguir esses ensinamentos, desfrutará dos benefícios que também aproveitamos e 
aprenderá a escrever códigos limpos e profissionais. Mas não pense você que nós estamos 100% 
“certos”. Provavelmente há outras escolas e mestres que têm tanto para oferecer quanto nós. O 
correto seria que você aprendesse com elas também. 

De fato, muitas das recomendações neste livro são contraditórias. Provavelmente você não 
concordará com todas e poderá até mesmo discordar intensivamente com algumas. Tudo bem. 
Não podemos querer ter a palavra final. Por outro lado, pensamos bastante e por muito tempo 
sobre as recomendações neste livro. As aprendemos ao longo de décadas de experiência е 
repetidos testes e erros. Portanto, concorde você ou não. seria uma pena se você não conseguisse 
enxergar nosso ponto de vista. 


Somos Autores 13 


Somos Autores 


O campo Gauthor de um Javadoc nos diz quem somos. Nós somos autores, e todo autor tem 
leitores, com os quais uma boa comunicação é de responsabilidade dos autores. Na próxima vez 
em que você escrever uma linha de código, lembre-se de que você é um autor, escrevendo para 
leitores que julgarão seus esforços. 

Você talvez se pergunte: o quanto realmente se lê de um código? A maioria do trabalho não 
é escrevê-lo? 

Você já reproduziu uma sessão de edição? Nas décadas de 1980 e 1990, tínhamos editores, 
como o Emacs, que mantinham um registro de cada tecla pressionada. Você podia trabalhar 
por horas e, então, reproduzir toda a sua sessão de edição como um filme passando em alta 
velocidade. Quando fiz isso, os resultados foram fascinantes. 

A grande maioria da reprodução era rolamento de tela e navegação para outros módulos! 


Bob entra no modulo. 

Ele descia até a função que precisava ser alterada. 

Ele para e pondera suas opções. 

Oh, ele sobe para o início do módulo a fim de verificar a inicialização da variável. 
Agora ele desce novamente e começa a digitar. 

Opa, ele está apagando o que digitou! 

Ele digita novamente. 

Ele apaga novamente. 

Ele digita a metade de algo e apaga! a 

Ele desce até outra função que chama a que ele está modificando para ver como ela é 
chamada. 

Ele sobe novamente e digita o mesmo código que acabara de digitar. 

Ele para. 

Ele apaga novamente! 

Ele abre uma outra janela e analisa uma subclasse. A função é anulada? 


Bem, você entendeu! Na verdade, a taxa de tempo gasto na leitura v. na escrita é de 10х1. 

Constantemente lemos um código antigo quando estamos criando um novo. 

Devido à tamanha diferença, desejamos que a leitura do código seja fácil, mesmo se sua 
criação for árdua. É claro que não há como escrever um código sem lê-lo, portanto torná-lo de 
fácil leitura realmente facilita a escrita. 

Não há como escapar desta lógica. Você não pode escrever um código se não quiser ler as 
outras partes dele. O código que você tenta escrever hoje será de dificil ou fácil leitura dependendo 
da facilidade de leitura da outra parte do código. Se quiser ser rápido. se quiser acabar logo, se 
quiser que seu código seja de fácil escrita, torne-o de fácil leitura. 
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A Regra de Escoteiro 


Não basta escrever um código bom. Ele precisa ser mantido sempre limpo. Todos já vimos 
códigos estragarem e degradarem com o tempo. Portanto, precisamos assumir um papel ativo na 
prevenção da degradação. 


A Boy Scouts of America (maior organização de jovens escoteiros dos EUA) tem uma regra 
simples que podemos aplicar à nossa profissão. 


Deixe a área do acampamento mais limpa do que como você a encontrou. 


Se todos deixássemos nosso código mais limpo do que quando o começamos, ele simplesmente 
não degradaria. A limpeza não precisa ser algo grande. Troque o nome de uma variável por um 
melhor, divida uma função que esteja um pouco grande demais, elimine um pouco de repetição 
de código, reduza uma instrução if aninhada. 

Consegue se imaginar trabalhando num projeto no qual o código simplesmente melhorou com 
o tempo? Você acredita que qualquer alternativa seja profissional? Na verdade, o aperfeiçoamento 
contínuo não é inerente ao profissionalismo? 


Prequela e Princípios 


Em muitas maneiras este livro é uma “prequela” de outro que escrevi em 2002, chamado Agile 
Sofiware Development: Principles. Patterns, and Practices (PPP). Ele fala sobre os princípios 
do projeto orientado a objeto e muitas das práticas utilizadas por desenvolvedores profissionais. 
Se vocé ainda nào leu o PPP, talvez ache que é a continuação deste livro. Se já o leu, então 
perceberá que ele é bastante parecido a esse em relação aos códigos. 

Neste livro há referências esporádicas a diversos princípios de projeto, dentre os quais estão: 
Princípio da Responsabilidade Única (SRP, sigla em inglês), Princípio de Aberto-Fechado (OCP. 
sigla em'inglés), Princípio da Inversão da Independência (DIP, sigla em inglês). dentre outros. 
Esses princípios são descritos detalhadamente no PPP. 


Conclusão 


Livros sobre arte não prometem lhe tornar um artista. Tudo o que podem fazer é lhe oferecer 
algumas das ferramentas, técnicas e linhas de pensamento que outros artistas usaram. Portanto, 
este livro não pode prometer lhe tornar um bom programador. Ou lhe dar a “sensibilidade ao 
código”. Tudo o que ele pode fazer é lhe mostrar a linha de pensamento de bons programadores 
e os truques, técnicas e ferramentas que eles usam. 

Assim como um livro sobre arte, este está cheio de detalhes. Há muitos códigos. Você verá 
códigos bons e ruins; código ruim sendo transformado em bom; listas de heurísticas, orientações 
e técnicas; e também exemplo após exemplo. Depois disso, é por sua conta. 

Lembre-se daquela piada sobre o violinista que se perdeu no caminho para a apresentação em 
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um concerto? Ele aborda um senhor na esquina e lhe pergunta como chegar ao Carnegie Hall. O 
senhor observa o violinista com seu violino debaixo dos braços е diz “Pratique, filho. Pratique!" 
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Nomes Significativos 


por Tim Ottinger 


Introdução 


Há nomes por todos os lados em um software. Nomeamos nossas variáveis, funções, parâmetros, 
classes e pacotes, assim como os arquivos-fonte e os diretórios que os possui. Nomeamos também 
nossos arquivos jar e war e ear. E nomeamos, nomeamos e nomeamos. Como fazemos muito isso, é 
melhor que o façamos bem. A seguir estão algumas regras simples para a criação de bons nomes. 
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Use Nomes que Revelem seu Propósito 


Dizer que os nomes devem demonstrar seu propósito é fácil. Mas queremos que você saiba que 
estamos falando sério. Escolher bons nomes leva tempo, mas economiza mais. Portanto, cuide 
de seus nomes e troque-os quando encontrar melhores. Todos que lerem seu código (incluindo 
você mesmo) ficarão agradecidos. 

O nome de uma variável. função ou classe deve responder a todas as grandes questões. Ele 
deve Ihe dizer porque existe, o que faz e como é usado. Se um nome requer um comentário, então 
ele não revela seu propósito. 


int d; // tempo decorrido em dias 


O nome d não revela nada. Ele não indica a ideia de tempo decorrido, nem de dias. Devemos 
escolher um nome que especifique seu uso para mensuração e a unidade usada. 


int elapsedTimeInDays; 
int daysSinceCreation; 
int daysSinceModification; 
int fileAgeInDays; 


Escolher nomes que revelem seu propósito pode facilitar bastante o entendimento e a alteração 
do código. Qual o propósito deste código? 


public List<int[]> getThem() ( 
List<int[]> list] = new ArrayList<int[]>(); 
for (int[] x : theList) 
if (x[0] == 4) 
listl.add(x); 
return listl; 


) 


Por que é dificil dizer o que o código faz? Não há expressões complexas. 

O espaçamento e a endentação são cabíveis. Só há três variáveis e duas constantes. Nem 
mesmo há classes refinadas ou métodos polimórficos, apenas uma lista de vetores (pelo menos 
é o que parece). O problema não é a simplicidade do código, mas seu aspecto implícito, isto é, o 
contexto não está explícito no código. Devido a isso, é necessário que saibamos as repostas para 
questões como: 


1. Que tipos de coisas estão em theList? 
2. Qual a importância de um item na posição zero na theList? 
3. Qual a importância do valor 4? 
4. Como eu usaria a lista retornada? 
As respostas para tais questões não estão presentes no exemplo do código, mas poderiam. 


Digamos que estejamos trabalhando num jogo do tipo “campo minado”. Percebemos que o 
tabuleiro é uma lista de células chamada theList. Vamos renomeá-la para gameBoard. 


Evite Informações Erradas 19 


Cada quadrado no tabuleiro é representada por um vetor simples. Mais tarde, descobrimos 
que a posição zero é armazena um valor de status e que o valor 4 significa “marcado com uma 
bandeirinha”, Ao dar esses nomes explicativos, podemos melhorar consideravelmente o código: 


public List<int[]> getFlaggedCells() ( 
List<int[]> flaggedCells = new ArrayList<int[]>(); 
for (int[] cell : gameBoard) 
if (cell[STATUS VALUE] 
flaggedCells.add(cell); 
return flagaedCells; 


FLAGGED) 


H 


Note que a simplicidade do código nào mudou. Ele ainda possui o mesmo número de 
operadores e constantes, com o mesmo número de itens aninhados. Entretanto, o código 
ficou muito mais explícito. 

Podemos continuar e criar uma classe simples para as células. em vez de usar um vetor ints. 

Ela pode ter uma função com um nome revele seu propósito (chamada i sF1agged, ou seja 
“está marcada com uma bandeirinha”) para ocultar os números mágicos. 

O resultado é uma nova versão da função: 


public List<Cell> getFlaggedCells() { 
List<Cell> flaggedCells = new ArrayList<Cell>(); 
for (Cell cell : gameBoard) 
if (cell.isFlagged()) 
flaggedCells.add(cell); 
return flaggedCells; 


} 


Com essas simples alterações de nomes. não fica difícil entender o que está acontecendo. Esse é 
o poder de escolher bons nomes. 


Evite Informações Erradas 


Os programadores devem evitar passar dicas falsas que confundam o sentido do código. 
Devemos evitar palavras cujos significados podem se desviar daquele que desejamos. Por 
exemplo, hp, aix e sco seriam nomes ruins de variáveis, pois são nomes de plataformas 
Unix ou variantes. Mesmo se estiver programando uma hipotenusa e hp parecer uma boa 
abreviação, o nome pode ser mal interpretado. 

Não se refira a um grupo de contas como accountList, a menos que realmente seja uma 
List. A palavra list (lista) significa algo específico para programadores. Se o que armazena as 
contas não for uma List de verdade, poderá confundir os outros.' Portanto, accountGroup ou 
bunchOfAccounts ou apenas accounts seria melhor. 

Cuidado ao usar nomes muito parecidos. Fica difícil perceber a pequena diferença 
entre  XYzControllerForEfficientHandlingOfStrings em шп módulo е 
XYZControllerForEfficientStorageOfStrings em outro. Ambas as palavras são 
muito semelhantes. 
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Usar conceitos similares para montar palavras é informação. Usar formatos inconsistentes 
para palavras leva a uma má interpretação. Com os ambientes Java de hoje dispomos do recurso 
de autocompletar palavras. Digitamos alguns caracteres de um nome e pressionamos uma 
combinação de teclas (se houver uma) e, então, aparece uma lista de possíveis palavras que 
se iniciam com tais letras. Isso é muito prático se houver nomes muito parecidos organizados 
alfabeticamente num mesmo local e se as diferenças forem óbvias, pois é mais provável que o 
desenvolvedor escolha um objeto pelo nome, sem consultar seus comentários ou mesmo a lista 
de métodos fornecidos por aquela classe. 

Um exemplo real de nomes que podem gerar confusão é o uso da letra “|” minúscula ou da 
vogal “o” maiúscula como nome de variáveis. O problema é que eles se parecem com o um e o 
zero, respectivamente. 


int a = 1; 

if ( Or== 1.) 
a = 01; 

else 

1 = 01; 


O leitor pode achar que inventamos esse exemplo, mas já vimos códigos nos quais isso 
acontecia bastante. Uma vez, o autor do código sugeriu o uso de fontes distintas de modo a 
realçar mais as diferenças, uma solução que teria de ser repassada de forma oral ou escrita a 
todos os futuros desenvolvedores. Com uma simples troca de nome, o problema é resolvido com 
objetividade e sem precisar criar novas tarefas. 


Faça Distinções Significativas 


Os programadores criam problemas para si próprios 
quando criam um código voltado unicamente para 
um compilador ou interpretador. Por exemplo, como 
não é possível usar o mesmo nome para referir-se 
a duas coisas diferentes num mesmo escopo, você 
pode decidir alterar o nome de maneira arbitrária. As 
vezes, isso é feito escrevendo um dos nomes errado, 
produzindo a uma situação na qual a correção de erros 
de ortografia impossibilita a compilação.” Não basta 
adicionar números ou palavras muito comuns, mesmo 
que o compilador fique satisfeito. Se os nomes precisam ser diferentes, então também devem ter 
significados distintos. 

Usar números sequenciais em nomes (al, a2,...,aN) é o oposto da seleção de nomes 
expressivos. Eles não geram confusão, simplesmente não oferecem informação alguma ou dica 
sobre a intenção de seu criador. Considere o seguinte: 


public static void copyChars(char ац], char a2[]) { 
for (int i = 0; i < al.length; i++) ( 
a2[i] = аці]; 
) 
Y 


a 


Use Nomes Pronunciáveis 


Fica muito mais fácil ler essa função quando usam-se source e destination como nomes 
de parâmetros. Palavras muito comuns são outra forma de distinção que nada expressam. 
Imagine que você tenha uma classe Product. Se houver outra chamada ProductInfo ou 
ProductData, você usou nomes distintos que não revelam nada de diferente. Info e Data são 
palavras muito comuns e vagas, como “um”, “uma” e “a”, 

Observe que não há problema em usar prefixos como “um” e “a”, contanto que façam 
uma distinção significativa. Por exemplo, você pode usar “um” para variáveis locais e “a” 
para todos os parâmetros de funções.’ O problema surge quando você decide chamar uma 
variável de aZork só porque já existe outra chamada zork. 

Palavras muito comuns são redundantes. O nome de uma variável jamais deve conter a 
palavra “variável”. O nome de uma tabela jamais deve conter a palavra tabela. Então como 
NameString é melhor do que Name? Um Name pode ser um número do tipo ponto flutuante? 
Caso possa, estaria violando uma regra sobre passar informações incorretas. Imagine que 
você encontre uma classe Customer e outra CustomerObject. O que a diferença nos nomes 
lhe diz? Qual seria a melhor para possuir o histórico de pagamento de um cliente? 

Conhecemos um aplicativo que é assim. A fim de proteger seus desenvolvedores, trocamos 
os nomes, mas abaixo está exatamente o tipo de erro: 


getActiveAccount(); 
getActiveAccounts(); 
getActiveAccountInfo(); 


Como os programadores desse projeto poderiam saber qual das trés funções chamar? 

Na ausência de convenções específicas, nào há como distinguir money Amount de money, 
customerlInfo de customer, accountData de account e theMessage de message. Faça a distinção 
dos nomes de uma forma que o leitor compreenda as diferenças. 


Use Nomes Pronunciáveis 


Os ser humano é bom com as palavras. Uma parte considerável de seu cérebro é responsável 
pelo conceito das palavras. E, por definição, as palavras são pronunciáveis. Seria uma lástima 
não tirar proveito dessa importante parte de nosso cérebro que evoluiu para lidar com a língua 
falada Sendo assim, crie nomes pronunciáveis. 

Se não puder pronunciá-lo, não terá como discutir sobre tal nome sem parecer um idiota. 
“Bem, aqui no bê cê erre três cê ene tê, temos um pé esse zê quê int, viram?”. Isso importa 
porque a programação é uma atividade social. 

Conheço uma empresa que possui uma variável genymdhms (generation date, year, 
month, day, hour, minute e second) e seus funcionários saem falando “gé dábliu eme dê aga 
eme esse”. Tenho um hábito irritante de pronunciar tudo como está escrito, portanto comecei 
a falar “gen-yah-muddahims”. 

Depois desenvolvedores e analistas estavam falando assim também, e ainda soava 
estúpido. Mas estávamos fazendo uma brincadeira e, por isso, foi divertido. Engraçado ou 
não, estamos tolerando nomeações de baixa qualidade. Novos desenvolvedores tiveram de 
pedir que lhes explicassem as variáveis, e, então, em vez de usar termos existentes na língua, 
inventavam palavras bobas ao pronunciá-las. Compare 
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class DtaRerd102 ( 
private Date genymdhms; 
private Date modymdhms; 
private final String pszqint = "102"; 
JE use fi 
N 


com 


class Customer ( 
private Date generationTimestamp; 
private Date modificationTimestamp;; 
private final String гесогата = “102°; 
querit 

н 


Agora é possível uma conversa inteligente: “Ei, Mikey, dê uma olhada este registro! A generation 
timestamp (“criação de marcação de horário”) está marcada para amanhã! Como pode?". 


Use Nomes Passíveis de Busca 


Nomes de uma só letra ou números possuem um problema em particular por não ser fácil localizá- 
los ao longo de um texto. Pode-se usar facilmente o grep para MAX CLASSES PER STUDENT, 
mas buscar o número 7 poderia ser mais complicado. Nomes, definições de constantes e várias 
outras expressões que possuam tal número, usado para outros propósitos podem ser resultados da 
busca. Pior ainda quando uma constante é um número grande e alguém talvez tenha trocado os 
dígitos, criando assim um bug e ao mesmo tempo não sendo captada pela busca efetuada. 

Da mesma forma, o nome “e” é uma escolha ruim para qualquer variável a qual um programador 
talvez precise fazer uma busca. É uma letra muito comum e provavelmente aparecerá em todo 
texto em qualquer programa. Devido a isso, nomes longos se sobressaem aos curtos, e qualquer 
nome passível de busca se sobressai a uma constante no código. 

Particularmente, prefiro que nomes com uma única letra só sejam usados como variáveis 
locais dentro de métodos pequenos. O tamanho de um nome deve ser proporcional ao 
tamanho do escopo. 

[N5]. Se uma variável ou constante pode ser vista ou usada em vários lugares dentro do código. 
é imperativo atribuí-la um nome fácil para busca. Novamente, compare 


for (int j=0; j<34; j++) ( 
s += (t[j]*4)/5; 
} 


com 


int realDaysPerIdealDay = 4; 
const int WORK DAYS PER WEEK = 
int sum = 0 
for (int j=0; j < NUMBER OF TASKS; j++) ( 
int realTaskDays = taskEstimate[j] * realDaysPerIdealDay; 
int realTaskWeeks = (realdays / WORK DAYS PER WEEK); 
sum += realTaskWeeks; 
) 
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Note que sum não é um nome prático, mas pelo menos é fácil de procurar. O nome usado no 
código serve para uma função maior, mas pense como seria muito mais fácil encontrar WORK_ 
DAYS PER WEEK do que buscar em todos os lugares nos quais o 5 aparece e, então, filtrar os 
resultados para exibir apenas as instâncias que você deseja. 


Evite Codificações 


Já temos de lidar com bastante codificação e não precisamos acrescentar mais. Codificar 
informações do escopo ou tipos em nomes simplesmente adiciona uma tarefa extra de decifração. 
Dificilmente parece lógico contratar um novo funcionário para aprender outra “linguagem” 
codificadora além da atual usada no código no qual se está trabalhando. É uma sobrecarga mental 
desnecessária ao tentar resolver um problema. Nomes codificados raramente são pronunciáveis, 
além de ser fácil escrevê-los incorretamente. 


A Notação Húngara 


Antigamente, quando trabalhávamos com linguagens com limite de tamanho para os nomes, 
violávamos essa regra quando necessário, com certo arrependimento. O Fortran forçava codificações 
ao tornar a primeira letra uma indicação para o tipo. Versões anteriores do BASIC só permitiam 
uma letra mais um dígito. A Notação Húngara (NH) inovou essas limitações. Na época da API em 
C do Windows, a NH era considerada muito importante, quando tudo era um inteiro ou um ponteiro 
para um inteiro long de 32 bits ou um ponteiro do tipo void, ou uma das diversas implementações 
de “strings” (com finalidades e atributos diferentes). O compilador não verificava os tipos naquele 
tempo, então os programadores precisavam de ajuda para lembrar dos tipos. 

Em linguagens modernas, temos tipos muito melhores, e os compiladores os reconhecem e os 
tornam obrigatórios. Ademais, há uma certa tendência para a criação de classes e funções menores. 
de modo que as pessoas possam ver onde cada variável que estão usando foi declarada. 

Os programadores Java não precisam definir o tipo. Os objetos já são o próprio tipo, e a edição 
de ambientes se tornou tão avançada que detectam quando se usa inadequadamente um tipo antes 
mesmo da compilação! Portanto, hoje em dia, a NH e outras formas de convenção de tipos são 
basicamente obstáculos. Eles dificultam a alteração do nome ou do tipo de uma variável, função 
ou classe; dificultam a leitura do código; e criam a possibilidade de que o sistema de codificação 
induza o leitor ao erro. 


PhoneNumber phoneString; 
// o nome nao muda na alteracao do tipo! 


Prefixos de Variáveis Membro 


Você não precisa mais colocar o prefixo т em variáveis membro. Mas para isso, suas classes e 
funções devem ser pequenas. E você deve usar um ambiente de edição que realce ou colore as 
variáveis membro de modo a distingui-las. 


public class Part ( 
private String m dsc; // Descrição textual 
void setName(String name) ( 
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public class Part ( 
String description; 
void setDescription(String description) ( 
this.description = description; 
) 
H 
Além disso, as pessoas rapidamente aprendem a ignorar o prefixo (ou sufixo) para visualizar 
a parte significativa do nome. Quanto mais lemos o código, menos prefixos enxergamos. No 
final, estes se tornam partes invisíveis e um indicativo de código velho. 


Interfaces e Implementações 


As vezes, há casos especiais para codificações. Por exemplo, digamos que você esteja construindo 
uma ABSTRACT FACTORY para criar formas. Essa factory será uma interface, e implementada 
por uma classe concreta. Como devemos nomeá-la? IShapeFactory e ShapeFactory? Prefiro 
não enfeitar as interfaces. О “I” no início, tão comum no hoje em dia, é na melhor das hipóteses 
uma distração, e na pior são informações excessivas. Não quero que meus usuários saibam 
que estou lhes dando uma interface, e, sim, apenas uma ShapeFactory. Portanto, se eu devo 
codificar seja a interface ou a implementação, escolho esta. Para codificar a interface. é preferível 
chamá-la de ShapeFactory Imp, ou mesmo de CShapeFactory. 


Evite o Mapeamento Mental 


Os leitores não devem ter de traduzir mentalmente os nomes que você escolheu por outros que 
eles conheçam. Essa questão costuma levar a decisão de não usar os termos do domínio do 
problema e nem os da solução. Este é um problema com nomes de variáveis de uma só letra. 
Certamente um contador de iterações pode ser chamado de “i”, “j” ou “к” (mas nunca 1) isso 
já se tornou uma tradição — se seu escopo for muito pequeno e não houver outros nomes que 
possam entrar em conflito com ele. 

Entretanto, na maioria dos contextos, um nome de uma só letra é uma escolha ruim; é apenas 
um armazenador que o leitor deverá mentalmente mapear de acordo com o conceito em uso. Não 
há razão pior do que usar o nome “с” só porque “а” e “b” já estão sendo usados. 

De maneira geral, os programadores são pessoas muito espertas. E esse tipo de pessoas gosta 
de se exibir mostrando suas habilidades mentais. Apesar de tudo, se você puder confiantemente 
se lembrar de que o “r” minúsculo é uma versão da url sem o host e o contexto, então obviamente 
você é muito esperto. 

Uma diferença entre um programador esperto e um programador profissional é que este 
entende que clareza é fundamental. Os profissionais usam seus poderes para o bem, e escrevem 
códigos que outros possam entender. 
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Nomes de Classes 


Classes e objetos devem ter nomes com substantivo(s), como Cliente, PaginaWiki, Conta € 
AnaliseEndereco. Evite palavras como Gerente, Processador, Dados ou Info no nome de uma 


classe, que também não deve ser um verbo. 


Nomes de Métodos 


Os nomes de métodos devem ter verbos, como postarPagamento, excluirPagina ou salvar. 
Devem-se nomear métodos de acesso, alteração e autenticação segundo seus valores e adicionar 
os prefixos get, set ou is de acordo com o padrão javabean.* 


string name - employee.getName(); 
customer.setName("mike"); 
if (paycheck.isPosted()) 


Quando os construtores estiverem sobrecarregados, use métodos factory estáticos com nomes 
que descrevam os parámetros. Por exemplo, 


Complex fulcrumPoint - Complex.FromRealNumber(23.0); 


é melhor do que 


Complex fulcrumPoint - new Complex(23.0); 


Para forçar seu uso, torne os construtores correspondentes como privados. 


Não dê uma de Espertinho 


Se os nomes forem muito “espertinhos”, 
apenas as pessoas que compartilhem do mesmo 
senso de humor que seu dono irão lembrá-los, 
e só enquanto se lembrarem da brincadeira. 
Eles saberão o que deve fazer a função 
HolyHandGrenade? Claro, é engraçado, mas 
talvez nesse caso DeleteTtems fique melhor. 
Opte por clareza no lugar de divertimento. 


Essas gracinhas em códigos costumam aparecer na forma de coloquialismos e gírias. Por 
exemplo, não use firmar () para significar terminar (). Não use piadas de baixo calão, 
como cairFora para significar abortar (). Diga o que você quer expressar. Expresse o 
que você quer dizer. 
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Selecione uma Palavra por Conceito 


Escolha uma palavra por cada conceito abstrato e fique com ela. Por exemplo, é confuso ter 
pegar, recuperar e obter como métodos equivalentes de classes diferentes. Como lembrar a 
qual método pertence cada classe? Infelizmente, você geralmente precisa se lembrar qual empresa, 
grupo ou pessoa criou a biblioteca ou a classe de modo a recordar qual termo foi usado, Caso 
contrário, você perde muito tempo vasculhando pelos cabeçalhos e exemplos de códigos antigos. 

Os ambientes modernos de edição. como o Eclipse e o IntelliJ, oferecem dicas relacionadas 
ao contexto, como a lista de métodos que você pode chamar em um determinado objeto. Mas 
note que a lista geralmente não lhe oferece os comentários que você escreveu em tomo dos 
nomes de suas funções. Você tem sorte se receber o parâmetro nomes (names) das declarações 
das funções. Os nomes das funções têm de ficar sozinhos, e devem ser consistentes de modo que 
você possa selecionar o método correto sem qualquer busca extra. 

Da mesma forma, é confuso ter um controlador, um gerenciador с um driver no 
mesmo código-fonte. Qual a principal diferença entre um GerenciadorDeDispositivo e um 
controlador-de-protocolo? Por que ambos não são controladores ougerenciadores? 
Ambos são realmente drivers? O nome faz com que você espere dois objetos com tipos bem 
distintos, assim como ter classes diferentes. 

Um léxico consistente é uma grande vantagem aos programadores que precisem usar 
seu código. 


Não Faça Trocadilhos 


Evite usar a mesma palavra para dois propósitos. Usar o mesmo termo para duas ideias diferentes 
é basicamente um trocadilho. 

Se você seguir a regra “uma palavra por conceito”, você pode acabar ficando com muitas 
classes que possuam, por exemplo, um método ada. Contanto que as listas de parâmetros e os 
valores retornados dos diversos métodos add sejam semanticamente equivalentes, tudo bem. 

Entretanto, uma pessoa pode decidir usar a palavra add por fins de “consistência” quando 
ela na verdade não aplica o mesmo sentido a todas. Digamos que tenhamos muitas classes nas 
quais add criará um novo valor por meio da adição e concatenação de dois valores existentes. 
Agora, digamos que estejamos criando uma nova classe que possua um método que coloque 
seu único parâmetro em uma coleção. Deveríamos chamar este método de ada? Por termos 
tantos outros métodos add, isso pode parecer consistente. Mas, neste caso, a semântica é 
diferente. Portanto, deveriamos usar um nome como inserir ou adicionar. Chamar este novo 
método de add seria um trocadilho. 

Nosso objetivo, como autores, é tornar a leitura de nosso código o mais fácil possível. 
Desejamos que nosso código seja de rápida leitura, e não um estudo demorado. Queremos usar a 
linguagem de um livro popular no qual é responsabilidade do autor ser claro, e não uma linguagem 
acadêmica na qual a tarefa do estudioso é entender minuciosamente o que está escrito. 


Use nomes a partir do Domínio da Solução 


Lembre-se de que serão programadores que lerão seu código. Portanto, pode usar termos de 
Informática, nomes de algoritmos, nomes de padrões, termos matemáticos etc. Não é prudente 
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pensar num nome a partir do domínio do problema, pois não queremos que nossos companheiros 
de trabalho tenham de consultar o cliente toda hora para saber o significado de um nome o qual 
eles já conhecem o conceito. só que por outro nome. 

O nome AccountVisitor ("conta do visitante") significa o bastante para um programador 
familiarizado com o padrão VISITOR, Qual programador não saberia o que é uma JobQueue 
(“fila de tarefas”)? Há muitas coisas técnicas que os programadores devem fazer. Selecionar 
nomes técnicos para tais coisas é, geralmente, o método mais adequado. 


Use nomes de Domínios do Problema 


Quando não houver uma solução “A la programador", use o nome do dominio do problema. Pelo 
menos o programador que fizer a manutenção do seu código poderá perguntar à um especialista 
em tal domínio o que o nome significa. 

Distinguir os conceitos do dominio do problema dos do domínio da solução é parte da tarefa 
de um bom programador e designer. O código que tem mais a ver com os conceitos do domínio 
do problema tem nomes derivados de tal domínio. 


Adicione um Contexto Significativo 


Há poucos nomes que são significativos por si só—a maioria não é. Por conta disso, você precisa 
usar nomes que façam parte do contexto para o leitor. Para isso você os coloca em classes, 
funções e namespaces bem nomeados. Se nada disso funcionar, então talvez como último recurso 
seja necessário adicionar prefixos ao nome. 

Imagine que você tenha variáveis chamadas firstName, last Name, street, houseNumber, 
city, state e zipcode. Vistas juntas, fica bem claro que elas formam um endereço. Mas e se 
você só visse a variável state sozinha num método? Automaticamente você assumiria ser parte 
de um endereço? 

Podem-se usar prefixos para adicionar um contexto: addrFirstName, addrLastName, 
addrState etc. Pelo menos os leitores entenderão que essas variáveis são parte de uma estrutura 
maior. É claro que uma melhor solução seria criar uma classe chamada Address. Então, até o 
compilador sabe que as variáveis pertencem a um escopo maior. 

Veja o método na Listagem 2.1. As variáveis precisam de um contexto mais significativo? O 
nome da função oferece apenas parte do contexto; o algoritmo apresenta o resto. 

Após ter lido a função, você vê que três variáveis. number, verb e pluralModifier, fazem 
parte da mensagem de dedução (guess statistics message). Infelizmente, o contexto deve ser 
inferido. Ao olhar pela primeira vez o método, o significado das variáveis não está claro. 
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Listagem 2-1 
Variáveis com contexto obscuro 
private void printGuessStatistics(char candidate, int count) ( 
String number; 
String verb; 
String pluralModifier; 
if (count == 0) ( 
number = “no*; 
verb = "Existem"; 
pluralModifier = "s"; 
else if (count 1) 1 
number = “1”; 
verb = “Existe” 
pluralModifier = *"; 
) else { 
number = Integer.toString(count) ; 
verb = “Existem”; 
pluralModifier = "s"; 


) 

String guessMessage = String.format( 

"There ts $s $s$s", verb, number, candidate, pluralModifier 
ve 

print (guessMessage) ; 


A função é um pouco extensa demais também e as variáveis são bastante usadas. A fim de 
dividir a função em partes menores, precisamos criar uma classe GuessStatisticsMessage 
е tornar as três variáveis como campos desta classe. Isso oferecerá um contexto mais claro 
para as três variáveis. Elas são definitivamente parte da GuessStatisticsMessage. A melhora do 
contexto também permite ao algoritmo ficar muito mais claro ao dividi-lo em funções menores 
(veja a Listagem 2.2). 


Listagem 2-2 
Variáveis possuem contexto 


public class GuessStatisticsMessage ( 
private String number; 
private String verb; 
private String pluralModifier; 


public String make(char candidate, int count) ( 
createPluralDependentMessageParts (count) ; 
return String.format( 
“There ts ts tsts*, 
verb, number, candidate, pluralModifier ): 
} 
private void createPluralDependentMessageParts {int count) { 
if (count 0) { 
thereareNoLetters(); 
) else if (count == 1) ( 
thereIsOneLetter(); 
) else ( 
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Listagem 2-2 (continuação) 
variáveis possuem contexto 


thereAreManyLetters (count); 
р) 
) 


private void thereAreManyLetters(int count) ( 
number = Integer.toString(count); 
verb = “Existem”; 
pluralModifier = “s”; 


Y 


private void thereIsOneLetter() ( 

number = "1*; 
verb = “Existe”; 
pluralModifier = *"; 

) 

private void thereareNoLetters() ( 
number = “no”; 
verb = “Existem”; 
pluralModifier = "s*; 


у 
} 
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Em um aplicativo fictício chamado “Gas Station Deluxe” (GSD). seria uma péssima ideia 
adicionar prefixos а toda classe com GSD. Para ser sincero, você estará trabalhando contra suas 
ferramentas. Você digita G e pressiona a tecla de autocompletar e recebe uma lista quilométrica de ^ 
cada classe no sistema. Isso é inteligente? Para que dificultar a ajuda da IDE? 

Da mesma forma, digamos que você inventou uma classe MailingAddress no módulo 
de contabilidade do GSD e que o chamou de GSDAccountAddress.Mais tarde. você precisa 
armazenar um endereço postal de seu cliente no aplicativo. Você usaria GSDAccountAddress? 
Parece que o nome é adequado? Dez dos 17 caracteres são redundantes ou irrelevantes. 

Nomes curtos geralmente são melhores contanto que sejam claros. Não adicione mais 
contexto a um nome do que o necessário. 

Os nomes accountAddress e customerAddress estão bons para instâncias da classe 
Address, mas seriam ruins para nomes de classes. Address está bom para uma classe. Se precisar 
diferenciar entre endereços MAC, endereços de portas e endereços da Web, uma ideia seria 
PostalAddress, MAC e URI. Os nomes resultantes são mais precisos, motivo esse da tarefa de 
se atribuir nomes. 


Conclusão 


O mais dificil sobre escolher bons nomes é a necessidade de se possuir boas habilidades de descrição 
e um histórico cultural compartilhado. Essa é uma questão de aprender, e não técnica, gerencial ou 
empresarial. Como consequência, muitas pessoas nessa área não aprendem essa tarefa muito bem. 
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Elas também têm receio de renomear as coisas por temer que outros desenvolvedores sejam 
contra. Não compartilhamos desse medo e achamos que ficamos realmente agradecidos quando 
os nomes mudam (para melhor). Na maioria das vezes, não memorizamos os nomes de classes 
e métodos. Mas usamos ferramentas modernas para lidar com detalhes de modo que possamos 
nos focalizar e ver se o código é lido como parágrafos, frases, ou pelo menos como tabelas е 
estruturas de dados (uma frase nem sempre é a melhor forma de se exibir dados). Provavelmente 
você acabará surpreendendo alguém quando renomear algo, assim como qualquer outra melhoria 
no código. Não deixe que isso atrapalhe seu progresso. 

Siga alguma dessas regras e note se você não melhorou a legibilidade de seu código. Se estiver 
fazendo a manutenção do código de outra pessoa, use ferramentas de refatoração para ajudar a 
resolver essas questões. Em pouco tempo valerá a pena, e continuará a vale em longo prazo. 


Nos primórdios da programação, formávamos nossos sistemas com rotinas e sub-rotinas. 
Já na era do Fortran e do PL/1, usávamos programas, subprogramas e funções. De tudo 
isso, apenas função prevaleceu. As funções são a primeira linha de organização em qualquer 
programa. Escrevê-las bem é o assunto deste capítulo. 
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Veja o código na Listagem 3.1. É dificil encontrar uma função grande em FitNesse', mas 
procurando um pouco mais encontramos uma. Além de ser longo, seu código é repetido, há 
diversas strings estranhas e muitos tipos de dados e APIs esquisitos e nada óbvios. Veja o quanto 
você consegue compreender nos próximos três minutos. 


Listagem 3-1 
HtmlUtil.java (FitNesse 20070619) 


public static String testableHtml( 
PageData pageData, 
boolean includeSuitesetup 
1 throws Exception ( 
WikiPage wikiPage = pageData.getWikiPage( 
StringBuf new StringBuffer | 
if (pageData. bute(*Test*)) { 
if (includeSuireserup) ( 
WikiPage suiteSetup = 
PageCrawlerImp1 .get InheritedPagei 
SuiteResponder.SUITE SETUP NAME, wikiPage 


if (suiteSetup !- null) ( 
WikiPagePath pagePath = 
suiteSetup.getPageCrawlert) .getFullPathisuiteset 
String pagePathName = PathParser.render (pagePath 
buffer .appendí" include -setup .") 
-append (pagePathName) 
“appendí Mn") 


) 
) 
WikiPage setup 
PageCrawlerImpl.gezInheritedPage(*SetUp*, wikiPagel; 
if (setup != null) ( 
WikiPagePath setupPath = 
wikiPage.getPageCrawler () .gerFullPath(setup) ; 
String setupPathName = PathParser.render(setupPath) ; 
buffer .append/" include -setup .*) 
.append(setupPathName) 
-аррепа ("\а") 


) 
buffer .append (pageData.getContent í} ) ; 
if ipageData.hasAttribute("Test")] ( 
WikiPage teardown - 
PageCrawlerImpl.getInheritedPage("TearDown*, wikiPage}; 
if (teardown != null) ( 
WikiPagePath tearDownPath - 
wikiPage.getPageCrawler().getFullPath(teardown); 
String tearDownPathName = PathParser.render (tearDownPath) ; 
butfer.append(*\n") 
.append (* lini 
“append (tea: 
append ("\n' 


ie -teardown .") 
sownPathName} 


ГОГ. n END СИ ТЕ eae ee end a 
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Listagem 3-1 (continuação) 
HtmlUtil.java (FitNesse 20070619) 
if (includeSuiteSetup) { 
WikiPage suiteTeardown - 
PageCrawlerImpl.getInheritedPage( 
SuiteResponder. SUITE TEARDOWN NAME, 
wikiPage 


); 
if (suiteTeardown null) ( 
WikiPagePath pagePath 
uiteTeardown.getPageCrawler().getFullPath (si 
String pageParhName = PathParser.render ipagePath) 
buífer.append(" include -teardown .*) 
„append (pagePathName) 
append (** 


Teardown| 


} 
pageData.setContent (buffer .tostring()); 
return pageData.getHtml(); 

1 


Conseguiu entender a função depois desses trés minutos estudando-a? Provavelmente nào. 
Há muita coisa acontecendo lá em muitos níveis diferentes de . Há strings estranhas e chamadas 
a funções esquisitas misturadas com dois i £ aninhados controlados por flags. 

Entretanto, com umas poucas extrações simples de métodos, algumas renomeações e um 
pouco de reestruturação.fui capaz de entender o propósito da função nas nove linhas da Listagem 
3.2. Veja se você consegue compreender também em três minutos. 


Listagem 3-2 
HtmlUtil.java (refatorado) 


public static String renderPageWithSetupsAndTeardowns ( 
PageData pageData, boolean isSuite 
) throws Exception { 
boolean isTestPage = pageData.hasAttribute(*Test"); 
if (isTestPage) { 
WikiPage testPage = pageData.getWikiPage(!; 
StringBuffer newPageContent = new StringBuffer |); 
includeSetupPages(testPage, newPageContent, isSuite); 
newPageContent . append (pageData . gecContent () ) ; 
includeTeardownPages (testPage, newPageContent, isSuite); 
pageData.setContent (newPageContent .toString()); 


return pageData.getHtml (1; 
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A menos que já estivesse estudando o FitNesse, provavelmente vocé nào entendeu todos 
os detalhes. 

Ainda assim você talvez tenha compreendido que essa função efetua a inclusão de algumas 
páginas SetUp e TearDown em uma página de teste e, então, exibir tal página em HTML. Se 
estiver familiarizado com о JUnit, você já deve ter percebido que essa função pertença a algum 
tipo de framework de teste voltado para a Web. E você está certo. Deduzir tal informação da 
Listagem 3.2 é muito fácil, mas ela está bastante obscura na Listagem 3.1. 

Então, o que torna uma função como a da Listagem 3.2 fácil de ler e entender? Como fazer 
uma função transmitir seu propósito? Quais atributos dar às nossas funções que permitirão um 
leitor comum deduzir o tipo do programa ali contido? 


Pequenas! 


A primeira regra para funções é que elas devem ser pequenas. A segunda é que precisam ser 
mais espertas do que isso. Não tenho como justificar essa afirmação. Não tenho referências de 
pesquisas que mostrem que funções muito pequenas são melhores. Só posso dizer que por cerca 
de quatro décadas tenho criado funções de tamanhos variados. Já escrevi diversos monstros de 
3.000 linhas; bastantes funções de 100 a 300 linhas; e funções que tinham apenas de 20 a 30 
linhas. Essa experiência me ensinou que, ao longo de muitas tentativas e erros, as funções devem 
ser muito pequenas. 

Na década de 1980, costumávamos dizer que uma função não deveria ser maior do que a tela. 

É claro que na época usávamos as telas VT100, de 24 linhas por 80 colunas, e nossos editores 
usavam 4 linhas para fins gerenciamento. Hoje em dia, com fontes reduzidas e um belo e grande 
monitor, você consegue colocar 150 caracteres em uma linha — não se deve ultrapassar esse 
limite—e umas 100 linhas ou mais por tela—as funções não devem chegar a isso tudo, elas 
devem ter no máximo 20 linhas. 

O quão pequena deve ser uma função? Em 1999, fui visitar Kent Beck em sua casa, em 
Oregon. EUA. Sentamo-nos e programamos um pouco juntos. Em certo ponto, ele me mostrou 
um simpático programa de nome Java/Swing o qual ele chamava de Sparkle. Ele produzia na 
tela um efeito visual similar a uma varinha mágica da fada madrinha do filme da Cinderela. 
Ao mover o mouse, faíscas (sparkles, em inglês) caíam do ponteiro do mouse com um belo 
cintilar até o fim da janela, como se houvesse gravidade na tela. Quando Kent me mostrou o 
código, fiquei surpreso com tamanha pequeneza das funções. Eu estava acostumado a funções 
que seguiam por quilômetros em programas do Swing. Cada função neste programa tinha apenas 
duas, ou trés, ou quatro linhas. Esse deve ser o tamanho das suas funções”. 

O quão pequenas devem ser suas funções? Geralmente menores do que a da Listagem 3.2! 
Na verdade, a Listagem 3.2 deveria ser enxuta para a Listagem 3.3. 
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Listagem 3-3 
HtmlUtil.java (refatorado novamente) 


boolean issuite) 
Data) ) 


ception ( 


isSuite); 


Blocos e Endentação 


Aqui quero dizer que blocos dentro de instruções if, else. while e outros devem ter apenas 
uma linha. Possivelmente uma chamada de função. Além de manter a função pequena, isso 
adiciona um valor significativo, pois a função chamada de dentro do bloco pode receber um 
nome descritivo. Isso também implica que as funções não devem ser grandes e ter estruturas 
aninhadas. Portanto, o nível de endentação de uma função deve ser de, no máximo, um ou dois. 
Isso, é claro, facilita a leitura e compreensão das funções. 


Faça Apenas uma Coisa 


Deve ter ficado claro que a Listagem 3.1 faz muito mais 
de uma coisa. Ela cria buffers, pega páginas. busca por 
páginas herdadas, exibe caminhos, anexa strings estranhas 
e gera HTML. dentre outras coisas. A Listagem 3.1 vive 
ocupada fazendo diversas coisas diferentes. Por outro 
lado, a Listagem 3.3 faz apenas uma coisa simples. Ela 
inclui SetUp e TearDown em páginas de teste. 

O conselho a seguir tem aparecido de uma forma ou 
de outra por 30 anos ou mais. 


AS FUNÇÕES DEVEM FAZER UMA COISA. DEVEM FAZÉ-LA BEM. 
DEVEM FAZER APENAS ELA. 


O problema dessa declaração é que é difícil saber o que é “uma coisa”. A Listagem 3.3 faz 
uma coisa? É fácil dizer que ela faz três: 


1. Determina se a página é de teste. 
2. Se for, inclui SetUps e TearDowns. 
3. Exibe a página em HTML. 

r 


Então, uma ou três coisas? Note que os três passos da função estão em um nivel de abaixo do 
nome da função. Podemos descrever a função com um breve parágrafo ТО“: 


4. A linguagem LOGO usava a palavra “TO” (“PARA que Ruby e Python usam “def”. Portanto, toda função começa com a palavra “TO”, 
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TO RenderPageWithSetupsAndTeardowns, verificamos se a página é de teste, se for. 
incluímos SetUps e TearDowns. Em ambos os casos, exibimos a página em HTML. 


Se uma função faz apenas aqueles passos em um nível abaixo do nome da função, então ela 
está fazendo uma só coisa, Apesar de tudo, o motivo de criarmos função é para decompor um 
conceito maior (em outras palavras, o nome da função) em uma série de passos no próximo nível 
de abstração. 

Deve estar claro que a Listagem 3.1 contém passos em muitos níveis diferentes de . Portanto. 
obviamente ela faz mais de uma coisa. Mesmo a Listagem 3.2 possui dois níveis de abstração 
+ como comprovado pela nossa capacidade de redução. Mas ficaria muito difícil reduzir a 
Listagem 3.3 de modo significativo. Poderíamos colocar a instrução i f numa função chamada 
includeSetupsAndTeardowns! fTest Page, mas isso simplesmente reformula o código, sem 
modificar o nível de . 

Portanto, outra forma de saber se uma função faz mais de “uma coisa” é se você pode 
extrair outra função dela a partir de seu nome que não seja apenas uma reformulação de sua 
implementação (G34). 


Seções Dentro de Funções 


Veja a Listagem 4.7 na página 71. Note que a função generatePrimes está dividida em 
seções, como declarações, inicializações e seleção. Esse é um indício óbvio de estar fazendo 
mais de uma coisa. Não dá para, de forma significativa, dividir em seções as funções que 
fazem apenas uma coisa. 


Um Nível de Abstração por Função 


A fim de confirmar se nossas funções fazem só “uma coisa”. Precisamos verificar se todas as 
instruções dentro da função estão no mesmo nível de abstração. É fácil ver como a Listagem 3.1 
viola essa regra. Há outros conceitos lá que estão em um nível de bem alto, como о getHtml (): 
outros que estão em um nível intermediário, como String pagePathName = PathParser. 
render  (pagePath); e outros que estão em um nível consideravelmente baixo, como 
«append (“tn”). 

Vários níveis de dentro de uma função sempre geram confusão. Os leitores podem não 
conseguir dizer se uma expressão determinada é um conceito essencial ou um mero detalhe. Pior, 
como janelas quebradas, uma vez misturados os detalhes aos conceitos, mais e mais detalhes 
tendem a se agregar dentro da função. 


Estrutura Switch 


Ler o Código de Cima para Baixo: Regra Decrescente 


Queremos que o código seja lido de cima para baixo, como uma narrativa. Desejamos que 
cada função seja seguida pelas outras no próximo nível de de modo que possamos ler o 
programa descendo um nível de de cada vez conforme percorremos a lista de funções. 
Chamamos isso de Regra Decrescente. 

Em outras palavras, queremos poder ler o programa como se fosse uma série de 
parágrafos TO. cada um descrevendo o nível atual de e fazendo referência aos parágrafos 
TO consecutivos no próximo nível abaixo. 


Para incluir SetUps e TearDowns, incluimos os primeiros. depois o conteúdo 
da página de teste e, então, adicionamos os segundos. Para incluir SetUps, 
adicionamos o suite setup, se este for uma coleção, incluimos o setup normal. 
Para incluir о suite setup, buscamos na hierarquia acima a página “SuiteSetUp” 
e adicionamos uma instrução de inclusão com o caminho àquela página. Para 
procurar na hierarquia acima... 


Acaba sendo muito difícil para os programadores aprenderem a seguir essa regra e criar 
funções que fiquem em apenas um nível de . Mas aprender esse truque é também muito 
importante, pois ele é o segredo para manter as funções curtas e garantir que façam apenas 
“uma coisa”. Fazer com que a leitura do código possa ser feita de cima para baixo como uma 
série de parágrafos TO é uma técnica eficiente para manter o nível de consistente. 

Veja a listagem 3.7 no final deste capítulo. Ela mostra toda a função testableHtml refatorada 
de acordo com os principios descrito aqui. Note como cada função indica a seguinte e como 
cada uma mantém um nível consistente de . 


Estrutura Switch 


É dificil criar uma estrutura switch pequena, pois mesmo uma com apenas dois cases é maior 
do que eu gostaria que fosse um bloco ou uma função. Também é dificil construir uma que fala 
apenas uma coisa. Por padrão, as estruturas switch sempre fazem N coisas. Infelizmente, nem 
sempre conseguimos evitar o uso do switch, mas podemos nos certificar se cada um está em 
uma classe de baixo nível e nunca é repetido. Para isso, usamos o polimorfismo. 

Veja a Listagem 3.4. Ela mostra apenas uma das operações que podem depender do tipo 
de funcionário (employee, em inglés). 
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Listagem 3-4 
Payroll.java 


public Money calculatePay (Employee ej 
throws InvalidEmployeeType ( 
switch (e.type) ( 
case COMMISSIONED 
return cal 
case HOU 
return calculateHourlyPay (e); 
case SALARIED. 
return calculatesalariêdPay (e); 
default: 
throw new InvalidEmployeeTypele.type); 


mmissionedPay (e) ; 


Esta função tem vários problemas. Primeiro, ela é grande, e quando se adiciona novos tipos de 
funcionários ela crescerá mais ainda. Segundo, obviamente ela faz mais de uma coisa. Terceiro, 
ela viola o Principio da Responsabilidade Única” (SRP, sigla em inglês) por haver mais de um 
motivo para alterá-la. Quarto, ela viola o Princípio de Aberto-Fechado* (OCP, sigla em inglês), 
pois precisa ser modificada sempre que novos tipos forem adicionados. Mas, provavelmente, o 
pior problema com essa função é a quantidade ilimitada de outras funções que terão a mesma 
estrutura. Por exemplo, poderíamos ter 


isPayday(Employee e, Date date) 
ou 
deliverPay(Employee e, Money рау) 


ou um outro grupo. Todas teriam a mesma estrutura deletéria. 

A solução (veja a Listagem 3.5) é inserir a estrutura switch no fundo de uma ABSTRACT 
FACTORY* e jamais deixar que alguém a veja. A factory usará o switch para criar instâncias 
apropriadas derivadas de Employee, e as funções, como calculatePay. isPayday е 
deliverPay, serão enviadas de forma polifórmica através da interface Employee. 

Minha regra geral para estruturas switch é que são aceitáveis se aparecerem apenas uma vez, 
como para a criação de objetos polifórmicos, e estiverem escondidas atrás de uma relação de 
herança de modo que o resto do sistema não possa enxergá-la [G23]. É claro que cada caso é um 
caso e haverá vezes que não respeitarei uma ou mais partes dessa regra. 


Listagem 
Employee e Factory 


public abstract class Employee ( 
public abstract boolean isPayday(); 


public abstract Money calculatePay(); 
public abstract void deliverPay(Money pay); 


itp: en wikipedia.org/wiki/Single responsibility principle 
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Use Nomes Descritivos 


Na Listagem 3.7, eu mudei o nome do exemplo de nossa função testableHtml para 
SetupTeardownIncluder.render, que é bem melhor, pois descreve o que a função faz. 
Também dei a cada método privado nomes igualmente descritivos, como isTestable ou 
includeSetupAndTeardownPages. É dificil superestimar o valor de bons nomes. Lembre-se 
do princípio de Ward: “Você sabe que está criando um código limpo quando cada rotina que 
vocé lé é como vocé esperava ". Metade do esforco para satisfazer esse princípio é escolher bons 
nomes para funções pequenas que fazem apenas uma coisa. Quando menor e mais centralizada 
for a função, mais fácil será pensar em um nome descritivo. 

Nao tenha medo de criar nomes extensos, pois eles são melhores do que um pequeno e 
enigmático. Um nome longo e descritivo é melhor do que um comentário extenso e descritivo. 
Use uma convenção de nomenclatura que possibilite uma fácil leitura de nomes de funções com 
várias palavras e, então, use estas para dar à função um nome que explique o que ela faz. 

Não se preocupe com o tempo ao escolher um nome. Na verdade, você deve tentar vários 
nomes e, então, ler o código com cada um deles. IDEs modernas, como Eclipse ou IntelliJ, 
facilita a troca de nomes. Utilize uma dessas IDEs e experimente diversos nomes até encontrar 
um que seja bem descritivo. 

Selecionar nomes descritivos esclarecerá o modelo do módulo em sua mente e lhe ajudará a 
melhorá-lo. É comum que ao buscar nomes adequados resulte numa boa reestruturação do código. 

Seja consistente nos nomes. Use as mesmas frases, substantivos e verbos nos nomes de funções 
de seu módulo. Considere, por exemplo, os nomes includeSetup-AndTeardownPages, 
includeSetupPages, includeSuiteSetupPage e includeSetupPage. A fraseologia 
nesses nomes permite uma sequência de fácil dedução. Na verdade. se eu lhe mostrasse 
apenas a série acima, você se perguntaria: “O que aconteceu com includeTeardownPages, 
includeSuiteTeardownPage e includeTeardownPage?", como isso é “... como o que 
você esperava?”. 


Parâmetros de Funções 


A quantidade ideal de parâmetros para uma função 
é zero (nulo). Depois vem um (mônade), seguido de 
dois (díade). Sempre que possível devem-se evitar 
três parâmetros (tríade). Para mais de três deve-se ter 
um motivo muito especial (políade) — mesmo assim 
não devem ser usados. 

Parâmetros são complicados. Eles requerem 
bastante conceito. É por isso que me livrei de 
quase todos no exemplo. Considere. por exemplo, 
o StringBuffer. Poderíamos tê-lo passado 
como parâmetro em vez de instanciá-lo como 
uma variável, mas então nossos leitores teriam 
de interpretá-lo sempre que o vissem. Ao ler a 
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estória contada por pelo módulo, fica mais fácil entender includesetupPage() do que 
includeSetupPageInto (newPage-Content). O parámetro nào está no nível de que o 
nome função, forçando-lhe reconhecer de um detalhe (ou seja, o StringBuffer) que não seja 
importante particularmente naquele momento. 

Os parâmetros são mais difíceis ainda a partir de um ponto de vista de testes. Imagine a 
dificuldade de escrever todos os casos de teste para se certificar de que todas as várias combinações 
de parâmetros funcionem adequadamente. Se não houver parâmetros, essa tarefa é simples. Se 
houver um, não é tão difícil assim. 

Com dois, a situação fica um pouco mais desafiadora. Com mais de dois, pode ser 
desencorajador testar cada combinação de valores apropriados. Os parâmetros de saída são ainda 
mais difíceis de entender do que os de entrada. Quando lemos uma função, estamos acostumados 
à ideia de informações entrando na função através de parâmetros e saindo através do valor 
retornado. Geralmente não esperamos dados saindo através de parâmetros. Portanto, parâmetros 
de saída costumam nos deixar surpresos e fazer com que leiamos novamente. 

Um parâmetro de entrada é a melhor coisa depois de zero parâmetro. É fácil entender 
SetupTeardown-Includer . render (pageData). Está óbvio que renderizemos os dados 
no objeto pageData. 


Formas Mônades Comuns 


Há duas razões bastante comuns para se passar um único parâmetro a uma função. Você pode estar 
fazendo uma pergunta sobre aquele parâmetro, como em boolean fileExists (“MyFile”). Ou 
você pode trabalhar naquele parâmetro, transformando-o em outra coisa e retornando-o. Por exemplo, 
InputStream fileOpen("MyFile") transforma a String do nome de um arquivo em um valor 
retomado por InputStream. São esses dois usos que os leitores esperam ver em uma função. 

Você deve escolher nomes que tornem clara a distinção, e sempre use duas formas em um 
contexto consistente. (Veja a seguir Separação comando-consulta). Uma forma menos comum 
mas ainda bastante útil de um parâmetro para uma função é um evento. Nesta forma, há um 
parâmetro de entrada, mas nenhum de saída. O programa em si serve para interpretar a chamada da 
função como um evento, e usar o parámetro para alterar o estado do sistema. por exemplo, void 
passwordAttemptFailedNtimes(int attempts). Use esse tipo com cautela. Deve ficar 
claro para o leitor que se trata de um evento. Escolha os nomes e os contextos com atenção. 

Tente evitar funções mónades que não sigam essas formas, por exemplo, void include 
SetupPageInto(StringBuffer  pageText). Usar um parâmetro de saída em vez de 
um valor de retorno para uma modificação fica confuso. Se uma função vai transformar seu 
parâmetro de entrada, a alteração deve aparecer como o valor retornado. De fato, StringBuffer 
transform(StringBuffer іп) é melhor do que void: transform-(StringBuffer 
out), mesmo que a implementação do primeiro simplesmente retorne o parâmetro de entrada. 
Pelo menos ele ainda segue o formato de uma modificação. 


Parâmetros Lógicos 


Esses parâmetros são feios. Passar um booleano para uma função certamente é uma prática horrível, 
pois ele complica imediatamente a assinatura do método, mostrando explicitamente que a função 
faz mais de uma coisa. Ela faz uma coisa se o valor for verdadeiro, e outra se for falso! 
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Na Listagem 3.7, não tínhamos alternativa, pois os chamadores já estavam passando 
aquela flag (valor booleano) como parâmetro. e eu queria limitar o escopo da refatoração à 
função e para baixo. Mesmo assim, a chamada do método render (true) é muito confusa 
para um leitor simples. Analisar a chamada e visualizar render (boolean isSuite) ajuda 
um pouco, mas nem tanto. Deveríamos dividir a função em duas: renderForSuite() e 
renderForSingleTest (). 


Funções Díades 


Uma função com dois parâmetros é mais difícil de entender do que uma com um (mônade). 
Por exemplo. é mais fácil compreender writeField (name) do que writeField (output- 
Stream, name)", Embora o significado de ambas esteja claro, a primeira apresenta seu propósito 
explicitamente quando a lemos. A segunda requer uma pequena pausa até aprendermos a ignorar o 
primeiro parâmetro. E isso, é claro, acaba resultando em problemas, pois nunca devemos ignorar 
qualquer parte do código. O local que ignoramos é justamente aonde se esconderão os bugs. 

Há casos, é claro, em que dois parâmetros são necessários como, por exemplo, em Point p 
= new Point (0,0). Os pontos de eixos cartesianos naturalmente recebem dois parâmetros. 
De fato, ficaríamos surpresos se víssemos new Point (0). Entretanto, os dois parâmetros neste 
caso são componentes de um único valor! Enquanto que output-Stream e name não são 
partes de um mesmo valor. 

Mesmo funções díades óbvias, como assertEquals (expected, actual), são 
problemáticas. 

Quantas vezes você já colocou actual onde deveria ser expected? Os dois parâmetros não 
possuem uma ordem pré-determinada natural. A ordem expected, actual é uma convenção que 
requer prática para assimilá-la. 

Díades não são ruins, e você certamente terá de usá-las, Entretanto, deve-se estar ciente de que 
haverá um preço a pagar e, portanto, deve-se pensar em tirar proveito dos mecanismos disponíveis 
a você para convertê-los em mónades. Por exemplo, você poderia tomar o método writeField 
um membro de output Stream de modo que pudesse dizer outputStreamwriteField (name); 
tornar output Stream uma variável membro da classe em uso de modo que não precisasse passá-lo 
por parâmetro; ou extrair uma nova classe, como Fieldwriter, que receba o outputStream em seu 
construtor e possua um método write. 


Tríades 


Funções que recebem três parâmetros são consideravelmente mais difíceis de entender do 
que as díades. A questão de ordenação, pausa e ignoração apresentam mais do que o dobro de 
dificuldade. Sugiro que você pense bastante antes de criar uma tríade. 

Por exemplo, considere a sobrecarga comum de assertEquals que recebe três parâmetros: 

assertEquals (message, expected, actual). Quantas vezes você precisou ler o 
parâmetro message e deduzir o que ele carrega? Muitas vezes já me deparei com essa tríade em 
particular e tive de fazer uma pausa. Na verdade, toda vez que a vejo, tenho de ler novamente e, 
então, a ignoro. 
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formato imbuímos os nomes dos parámetros no nome da funcáo. Por exemplo, pode ser melhor 
escrever assertEquals do que assertExpectedEqualsActual(expected, actual), 0 
que resolveria o problema de ter de lembrar a ordem dos parámetros. 


Evite Efeitos Colaterais 


Efeitos colaterais são mentiras. Sua função promete fazer apenas uma coisa, mas ela também faz 
outras coisas escondida. Às vezes, ela fará alterações inesperadas nas variáveis de sua própria 
classe. Às vezes, ela adicionará as variáveis aos parâmetros passados à função ou às globais 
do sistema. Em ambos os casos elas são “verdades” enganosas e prejudiciais, que geralmente 
resultam em acoplamentos temporários estranhos e dependências. 

Considere, por exemplo, a função aparentemente inofensiva na Listagem 3.6. Ela usa um 
algoritmo padrão para comparar um userName (nome de usuário) а um password 
(senha). Ela retoma true (verdadeiro) se forem iguais, с false (falso) caso contrário. 
Mas há também um efeito colateral. Consegue identificá-lo? 


Listagem 3-6 
UserValidator. java 


public class Uservalida: 
private Cryptographer с. 


ptographer; 


public boolean checkPassword (String userName, String password) { 
User user = UserGateway.findByName (userName) ; 
if (user != User.NULL) ( 
String codedPhrase = user.getPhraseEncodedByPassword(); 
String phrase = cryptographer.decrypt (codedPhrase, password): 
if ("Valid Password" .equals (phrase)) ( 
Session.initialize(); 
return true; 


return false; 


O efeito colateral é a chamada ao Session.initialize(), é claro. A função 
checkPassword, segundo seu nome, diz que verifica a senha. O nome não indica que ela 
inicializa a sessão. Portanto, um chamador que acredita no que diz o nome da função corre o 
risco de apagar os dados da sessão existente quando ele decidir autenticar do usuário. 

Esse efeito colateral cria um acoplamento temporário. Isto é, checkPassword só poderá ser 
chamado em determinadas horas (em outras palavras, quando for seguro inicializar a sessão). Se 
for chamado fora de ordem, sem querer, os dados da sessão poderão ser perdidos. Os acoplamentos 
temporários são confusos, especialmente quando são um efeito colateral. Se for preciso esse tipo 
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de acoplamento, é preciso deixar claro no nome da função. Neste caso, poderiamos renomear 
a função para checkPasswordAndInitializeSession, embora isso certamente violaria o 
“fazer apenas uma única coisa”. 


Parâmetros de Saída 


Os parâmetros são comumente interpretados como entradas de uma função. Se já usa o programa 
há alguns anos, estou certo de que você já teve de voltar e ler novamente um parámetro que era, 
na verdade, de saída, e não de entrada. Por exemplo: 


appendFooter(s); 


Essa função anexa s como rodapé (Footer, em inglês) em algo? Ou anexa um rodapé a s? s é 
uma entrada ou uma saída? Não precisa olhar muito a assinatura da função para ver: 


public void аррепағообег (StringBuffer report) 


Isso esclarece a questão, mas à custa da verificação da declaração da função. Qualquer coisa 
que Ihe force a verificar a assinatura da função é equivalente a uma relida. Isso é uma interrupção 
do raciocinio e deve ser evitado. 

Antes do surgimento da programação orientada a objeto, às vezes era preciso ter parâmetros de 
saida. Entretanto, grande parte dessa necessidade sumiu nas linguagens OO, pois seu propósito é servir 
como um parâmetro de saida. Em outras palavras, seria melhor invocar appendFooter como: 


report .appendFooter(); 


De modo geral, devem-se evitar parâmetros de saída. Caso sua função precise alterar o estado 
de algo, faça-a mudar o estado do objeto que a pertence. 


Separação comando-consulta 


As funções devem fazer ou responder algo, mas não ambos. Sua função ou altera o estado de 
um objeto ou retorna informações sobre ele. Efetuar as duas tarefas costuma gerar confusão. 
Considere, por exemplo, a função abaixo: 


public boolean set(String attribute, String value); 


Esta função define o valor de um dado atributo e retorna true (verdadeiro) se obtiver 
êxito е false (falso) se tal atributo não existir. Isso leva a instruções estranhas como: 


if (set(*username*, "unclebob"))... 


Imagine isso pelo ponto de vista do leitor. O que isso significa? Está perguntando se o atributo 
"username" anteriormente recebeu o valor *unclebob"? Ou se "username" obteve éxito ao 
receber o valor “unclebob”? É difícil adivinhar baseando-se na chamada, pois não está claro se 


a palavra “set” é um verbo ou um adjetivo. 
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O intuito do autor era que set fosse um verbo, mas no contexto da estrutura if, parece 
um adjetivo. Portanto, a instrução lê-se “Se o atributo username anteriormente recebeu o valor 
unclebob” e não “atribua o valor unclebob ao atributo username, e se isso funcionar, então...”. 
Poderíamos tentar resolver isso renomeando a função set para setAndCheckIfExists, mas 
não ajudaria muito para a legibilidade da estrutura if. 


if (attributeExists(*username")) ( 
setAttribute(“username”, "unclebob"); 


Prefira exceções a retorno de códigos de erro 


Fazer funções retornarem códigos de erros é uma leve violação da separação comando-consulta, 
pois os comandos são usados como expressões de comparação em estruturas if. 


if (deletePage(page) 


E OK) 


O problema gerado aqui nào é a confusão verbo/adjetivo, mas sim a criação de estruturas 
aninhadas. 

Ao retornar um código de erro, você cria um problema para o chamador, que deverá lidar 
imediatamente com o erro. 


if (deletePage(page) == E. OK) ( 
if (registry.deleteReference(page.name) == E OK) ( 
if (configKeys.deleteKey(page.name.makeKey()) == E OK)( 
logger.log(“página excluída"); ^ 
) else { 


logger.log(“configkey não foi excluída"); 
} 


} else { 
logger.log("deleteReference não foi excluído do 
registro"); 
) 
) else ( 


logger.log(*a exclusão falhou”); 
return E ERROR; 
) 


Por outro lado, se você usar exceções em vez de retornar códigos de erros, então o código de 
tratamento de erro poderá ficar separado do código e ser simplificado: 
4 

£x t 
deletePage(page); 
registry.deleteReference(page.name); 
configKeys.deleteKey(page.name.makeKey()); 

) 

catch (Exception e) ( 
logger.log(e.getMessage()); 

} 


46 Capítulo 3: Funções 


Extraia os blocos try/catch 


Esses blocos não têm o direito de serem feios. Eles confundem a estrutura do código e misturam 
о tratamento de erro com o processamento normal do código. Portanto, é melhor colocar as 
estruturas try e catch em suas próprias funções. 


public void delete(Page page) ( 
try { 
deletePageAndAllReferences(page); 
} 
catch (Exception e) ( 
logError (е); 
) 
) 


private void deletePageAndAllReferences(Page page) throws Exception 


" 


deletePage(page); 

registry.deleteReference(page.name); 

configkeys.deletekey (page.name.makeKey()); 
} 


private void logError(Exception e) { 
logger.log(e.getMessage()); 
) 


A função delete acima só faz tratamento de erro. E é fácil entendé-la e seguir adiante. 
A função deletePageAndAllReferences só trata de processos que excluem toda uma 
página. Pode-se ignorar o tratamento de erro. Isso oferece uma boa separação que facilita a 
compreensão e alteração do código. 


Tratamento de erro é uma coisa só 


As funções devem fazer uma coisa só. Tratamento de erro é uma coisa só. Portanto, uma 
função que trata de erros não deve fazer mais nada. Isso implica (como no exemplo acima) 
que a palavra try está dentro de uma função e deve ser a primeira instrução e nada mais deve 
vir após os blocos catch/finally. 


Error.java, o chamariz à dependência 


Retornar códigos de erro costuma implicar que há classes ou enum nos quais estão definidos 
todos os códigos de erro. 4 


public enum Error { 
OK, 
INVALID, 
NO. SUCH, 
LOCKED, 
OUT OF RESOURCES, 
WAITING FOR EVENT; 
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Classes como esta são chamarizes à dependência, muitas outras classes devem importá-las 
e usá-las. Portanto. quando o enum da classe Error enum, é preciso recompilar todas as outras 
classes e redistribuí-las'. Isso coloca uma pressão negativa na classe Error. Os programadores não 
querem adicionar novos erros porque senão eles teriam de compilar e distribuir tudo novamente. 
Por isso, eles reutilizam códigos de erros antigos em vez de adicionar novos. 

Quando se usam exceções em vez de códigos de erro, as novas exceções são derivadas da 
classe de exceções. Podem-se adicioná-las sem ter de recompilar ou redistribuir". 


Evite repetição: 


Leia novamente com atenção a Listagem 3.1 e notará 
que há um algoritmo que se repete quatro vezes em 
quatro casos: SetUp, SuiteSetUp, TearDown € 
SuiteTearDown. Não é fácil perceber essa duplicação, 
pois as quatro instâncias estão misturadas com outros 
códigos e não estão uniformemente repetidas. Mesmo 
assim, a duplicação é um problema, pois ela amontoa 
o código e serão necessárias quatro modificações se o 
algoritmo mudar. Além de serem quatro oportunidades 
para a omissão de um erro. 

Sanou-se essa duplicação através do método include na Listagem 3.7. Leia este códigonovamente 
e note como a legibilidade do módulo inteiro foi melhorada com a retirada de tais repetições. 

A duplicação pode ser a raiz de todo o mal no software. Muitos princípios e práticas têm 
sido criados com a finalidade de controlá-la ou eliminá-la. Considere, por exemplo, que todas 
as regras de normalização de bando de dados de Ted Codd servem para eliminar duplicação” 
de dados. Considere também como a programação orientada a objeto serve para centralizar o 
código em classes-base que seriam outrora redundantes. Programação estruturada, Programação 
Orientada a Aspecto e Programação Orientada a Componentes são todas, em parte, estratégias 
para eliminar duplicação de código. Parece que desde a invenção da sub-rotina, inovações no 
desenvolvimento de software têm sido uma tentativa contínua para eliminar a duplicação de 
nossos códigos-fonte. 


Programação estruturada 


Alguns programadores seguem as regras programação estruturada de Edsger Dijkstra", que disse 
que cada função e bloco dentro de uma função deve fer uma entrada e uma saída. Cumprir essas 
regras significa que deveria haver apenas uma instrução return na função, nenhum break ou 
continue num loop e jamais um goto. 

Enquanto somos solidários com os objetivos e disciplinas da programação estruturada, tais 
regras oferecem pouca vantagem quando as funções são muito pequenas. Apenas em funções 
maiores tais regras proporcionam benefícios significativos. 

Portanto, se você mantiver suas funções pequenas, então as várias instruções return, break 
ou continue casuais não trarão problemas e poderão ser até mesmo mais expressivas do que 


1 Aqueles que pensaram que poderiam sc livrar da recompilação c da redistribuição foram encontrados, e tomadas as devidas providências. 
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a simples regra de uma entrada e uma saída. Por outro lado, o goto só faz sentido em funções 
grandes, portanto ele deve-se evitá-lo. 


Como escrever funções como essa? 


Criar um software é como qualquer outro tipo de escrita. Ao escrever um artigo, você primeiro 
coloca seus pensamentos no papel e depois os organiza de modo que fiquem fáceis de ler. O 
primeiro rascunho pode ficar desastroso e desorganizado, então você o apare, reestrutura e refina 
até que ele fique como você deseja. 

Quando escrevo funções, elas começam longas e complexas; há muitas endentações e loops 
aninhados; possuem longas listas de parâmetros; os nomes são arbitrários; e há duplicação de 
código. Mas eu também tenho uma coleção de testes de unidade que analisam cada uma dessas 
linhas desorganizadas do código. 

Sendo assim, eu organizo e refino o código, divido funções. troco os nomes, elimino a 
duplicação, reduzo os métodos e os reorganizo. Às vezes, desmonto classes inteiras, tudo com 
os testes em execução. 

No final, minhas funções seguem as regras que citei neste capítulo. Não as aplico desde o 
início. Acho que isso não seja possível. 


Conclusão 


Cada sistema é construído a partir de uma linguagem específica a um domínio desenvolvida por 
programadores para descrever o sistema. As funções são os verbos dessa linguagem, e classes 
os substantivos. Isso não é um tipo de retomada da antiga noção de que substantivos e verbos 
nos requerimentos de um documento sejam os primeiros palpites das classes e funções de um 
sistema. Mas sim uma verdade muito mais antiga. A arte de programar é, e sempre foi, a arte do 
projeto de linguagem. 

Programadores experientes veem os sistemas como histórias a serem contadas em vez de 
programas a serem escritos. Eles usam os recursos da linguagem de programação que escolhem 
para construir uma linguagem muito mais rica e expressiva do que a usada para contar a estória. 
Parte da linguagem específica a um domínio é a hierarquia de funções que descreve todas as 
ações que ocorrem dentro daquele sistema. Em um ato engenhoso, escrevem-se essas funções 
para usar a mesma linguagem específica a um domínio que eles criaram para contar sua própria 
parte da história. 

Este capítulo falou sobre a mecânica de se escrever bem funções. Se seguir as regras aqui descritas. 
suas funções serão curtas, bem nomeadas e bem organizadas. Mas jamais se esqueça de que seu 
objetivo verdadeiro é contar a história do sistema, e que as funções que você escrever precisam estar 
em perfeita sincronia e formar uma linguagem clara e precisa para lhe ajudar na narração. 


SetupTeardownIncluder 


SetupTeardownIncluder 
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Listagem 3-7 
SetupTeardownIncluder. java 


package fitnesse.html; 


import fitnesse.responders.run.SuiteResponder; 
import fitnesse.wiki.*; 

public class SetupTeardownIncluder { 
private PageData pageData; 

private boolean issuite; 

private WikiFage testPage; 

private StringBuffer newPageContent; 
private PageCrawler pageCrawler; 


public static String render(PageData pageData) throws Exception 
return render(pageData, false); 
) 


public static String render(PageData pageData, boolean isSuite) 
throws Exception { 
return new SetupTeardownIncluder (pageData) . render (isSuite) ; 


гасе SetupTeardownIncluder (PageData pageData) ( 
this.pageData = pageData; 
testPage = pageData.getWikiPage(); 
pageCrawler = testPage.getPageCrawler i); 
newPageContent - new StringBuffer(); 

) 


private String render(boolean isSuite) throws Exception ( 
this.isSuite = isSuite; 
if (isTestPage()) 
includeSetupAndTeardownPages () ; 
return pageData.getHtml(!; 


private boolean isTestPage() throws Exception { 
return pageData.hasAttribute ("Test"); 
} 


private void includeSetupandTeardownPages () throws Exception { 
includeSetupPages |} ; 
includePageContent () ; 
includeTeardownPages () ; 
updatePageContent () ; 
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Listagem 3-7 (continuação): 
SetupTeardownIncluder. java 


private void includeSetupPages() throws Exception { 
if (isSuite) 
includeSuiteSetupPage | ; 
includeSetupPage(): 
} 


private void includeSuiteSetupPagel) throws Exception { 
includeiSuiteResponder.SUITE SETUP NAME, *-setup']; 

} 

private void includeSetupPage(! throws Exception { 
include("SetUp", *-setup"); 

i 


private void includePageContent () throws Exception { 
newPageContent append (pageData. getContent () ) ; 
) 


private void includeTeardownPages({} throws Exception ( 
includeTeardownPage |) ; 
if lisSuite) 
includeSuiteTeardownPage(!; 


) 


private void includeTeardownPage() throws Exception ( 
include ("TearDown", "-teardown") ; 
) 


private void includeSuiteTeardownPage() throws Exception { 
include(SuiteResponder.SUITE TEARDOWN NAME, *-teardown*!: 
H 


private void updatePageContent() throws Exception ( 
pageData, set Content (newPageContent . toString()]; 


private void includeiString pageName, String arg) throws Exception { 
WikiPage inheritedPage = findInheritedPage (pageName) ; 
if (inheritedPage !- null) ( 
String pagePathName = getPathNameForPage (inheritedPage) ; 
buildincludeDirective(pagePathName, arg); 
) 
) E 


private WikiPage findInheritedPage (String pageName) throws Exception ( 
return PageCrawlerImpl.getInheritedPage(pageName, testPage): 

private String getPathNameForPage(WikiPage page) throws Exception { 
WikiPagePath pagePath = pageCrawler.getFullPath(page) ; 
return PathParser.render (pagePath) ; 

) 


private void buildIncludeDirectiveiString pagePathName, String arg) ( 
newPageContent 
.append(*\n!include *j 
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Comentários 


ão insira comentários num código ruim, reescreva-o”. 


—Brian W. Kernighan е. J. Plaugher' 


Nada pode ser tão útil quanto um comentário bem colocado. Nada consegue amontoar um 
módulo mais do que comentários dogmáticos e supérfluos. Nada pode ser tão prejudicial quanto 
um velho comentário mal feito que dissemina mentiras e informações incorretas. 

Comentários não são como a Lista de Schindler. Não são o “bom puro”. De fato, eles são, 
no máximo, um mal necessário. Se nossas linguagens de programação fossem expressivas o 
suficiente ou se tivéssemos o talento para manipular com destreza tais linguagens de modo a 
expressar nossa intenção, não precisaríamos de muitos comentários, quiçá nenhum. 


54 Capítulo 4: Comentários 


O uso adequado de comentários é compensar nosso fracasso em nos expressar no código. 
Observe que usei a palavra fracasso. E é isso que eu quis dizer. Comentários são sempre fracassos. 
Devemos usá-los porque nem sempre encontramos uma forma de nos expressar sem eles. mas 
seu uso não é motivo para comemoração. 

Então, quando você estiver numa situação na qual precise criar um comentário, pense bem 
e veja se não há como se expressar através do código em si. Toda vez que você fizer isso, dê em 
si mesmo um tapinha de aprovação nas costas. Toda vez que você escrever um comentário, faça 
uma careta e sinta о fracasso de sua capacidade de expressão. 

Por que sou não gosto de comentários? Porque eles mentem. Nem sempre, e não 
intencionalmente, mas é muito comum. Quanto mais antigo um comentário for e quanto mais 
longe estiver do código o qual ele descreve, mais provável será que esteja errado. O motivo é 
simples. Não é realístico que programadores consigam mantê-los atualizados. 

Códigos mudam e evoluem. Movem-se blocos para lá e para cá. que se bifurcam e se reproduzem 
ese unem novamente, formando monstros gigantescos. Infelizmente, os comentários nem sempre os 
seguem — nem sempre é possível. E, muito frequentemente, os comentários ficam longe do código 
o qual descrevem e se tornam dizeres órfãos com uma exatidão cada vez menor. Por exemplo. olhe 
o que aconteceu com o comentário abaixo e a linha que ele procurava descrever: 


MockRequest request; 

private final String HTTP DATE REGEXP = 
"[SMTWF] [a-z] (2)W, Ns [0-9] (27 Ws [JFMASOND] [a-z] {2}\\s"+ 
*[0-9] {4}\\s [0-9] (2): [0-9] (2): [0-9] (2) NSGMT"; 

private Response response; 

private FitNesseContext context; 

private FileResponder responder: 

private Locale saveLocale; 

// Exemplo: "Tue, 02 Apr 2003 22:18:49 GMT" 


Outras instâncias de variáveis que provavelmente foram adicionadas posteriormente ficaram 
entre a constante HTTP. DATE. REGEXP e seu comentário descritivo. 

É possível dizer que os programadores deveriam ser disciplinados o bastante para manter 
os comentários em um elevado estado de atualização, relevância e precisão. Concordo que 
deveriam. Mas cu preferiria que essa energia fosse direcionada para tornar o código tão claro e 
descritivo que de início nem se precisaria de comentários. 

Comentários imprecisos são muito piores do que nenhum. Eles enganam е iludem; deixam 
expectativas que jamais serão cumpridas; citam regras antigas que não precisariam mais, ou não 
deveriam, ser seguidas. Р 

Só se pode encontrar a verdade ет um lugar: no código. Só ele pode realmente lhe dizer o que 
ele faz. Ele é a única fonte de informações verdadeiramente precisas. Entretanto, embora às vezes 
comentários sejam necessários, gastaríamos energia considerável para minimiza-los. 


Comentários Compensam um Código Ruim 


Uma das motivações mais comuns para criar comentários é um código ruim. Construímos um 
módulo e sabemos que está confuso e desorganizado. Estamos cientes da bagunça. Nós mesmos 
dizemos “Oh, é melhor inserir um comentário!”. Não! É melhor limpá-lo. 


= 
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Códigos claros e expressivos com poucos comentários são de longe superiores a um amontoado 
e complexo com muitos comentários. Ao invés de gastar seu tempo criando comentários para 
explicar a bagunça que você fez, use-o para limpar essa zona. 


Explique-se no código 


Certamente há vezes em que não é possível se expressar direito no código. Infelizmente, devido 
a isso, muitos programadores assumiram que o código raramente é, se é que possa ser, um bom 
meio para se explicar. Evidentemente isso é falso. O que você preferiria ver? Isso: 


// Verifica se o funcionario tem direito a todos os beneficios 
if ((employee.flags & HOURLY FLAG) && 
(employee.age > 65)) 
Ou isso? 
if (employee.isEligibleForFullBenefits()) 


Só é preciso alguns segundos de pensamento para explicar a maioria de sua intenção no 
código. Em muitos casos, é simplesmente uma questão de criar uma função cujo nome diga a 
mesma coisa que você deseja colocar no comentário. 


Comentários Bons 


Certos comentários são necessários ou benéficos. Veremos alguns que considero valerem os 
bits que consumem. Tenha em mente, contudo, que o único comentário verdadeiramente bom é 
aquele em que você encontrou uma forma para não escrevê-lo. 


Comentários Legais 


Às vezes, nossos padrões de programação corporativa nos forçam a escrever certos comentários 
por questões legais. Por exemplo, frases sobre direitos autorais e autoria são informações 
necessárias e lógicas para se colocar no início de um arquivo fonte. 

Por exemplo, abaixo está o comentário padrão de cabeçalho que colocamos no início de todo 
arquivo fonte do FitNesse. Fico feliz em dizer que nossa IDE evita a união automática desse 
comentário para que não fique aglomerado. 


// Direitos autorais (C) 2003,2004,2005 por Object Mentor,"Inc. Todos 
os direitos reservados. 

// Distribuido sob os termos da versão 2 ou posterior da Licenca 
Publica Geral da GNU. 


Comentários como esse nào devem ser contratos ou tomos legais. Onde for possível, faca 
referência a uma licença padrão ou outro documento externo em vez de colocar todos os termos 
e condições no mesmo comentário. 
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Comentários Informativos 


Às vezes é prático fornecer informações básicas em um comentário. Por exemplo, considere o 
comentário abaixo que explica o valor retornado de um método abstrato: 


// Retorna uma instancia do Responder sendo testado. 
protected abstract Responder responderInstance(); 


Um comentário como este pode ser útil às vezes, mas, sempre que possível, é melhor usar o 
nome da função para transmitir a informação. Por exemplo, neste caso, o comentário ficaria 
redundante se trocássemos o nome da função: responderBeingTested. 

Assim ficaria um pouco melhor: 


// formato igual a kk:mm:ss EEE, MMM dd, aaaa 
Pattern timeMatcher = Pattern.compile("\\d* 


*:\\а* Awt, Ww* Wd*, \\а*”); 


Neste caso, o comentário nos permite saber que a expressão regular deve combinar com uma 
hora e data formatadas com a função SimpleDateFormat format usando a string específica com 
o formato. Mesmo assim, teria ficado melhor e mais claro se esse código tivesse sido colocado 
em uma classe especial para converter os formatos de datas e horas. Então, o comentário 
provavelmente seria supérfluo. 


Explicação da intenção 


Às vezes, um comentário vai além de ser apenas informações úteis sobre a implementação e 
fornece a intenção por trás de uma decisão. No caso a seguir, vemos uma decisão interessante 
documentada através de um comentário. Ao comparar dois objetos, o autor decidiu que queria 
classificar como superiores os objetos de sua classe em relação aos de outras. 


public int compareTo(Object o) 
i 
if(o instanceof WikiPagePath) 
t 
WikiPagePath p - (WikiPagePath) o; 
String compressedName = StringUtil.joininames, ""); 
String compressedArgumentName - StringUtil.join(p.names, ""); 
return compressedName.compareTo(compressedArgumentName); 
) ^ 
return 1; // somos superiores porque somos tipo certo. 
$ 


Abaixo está um exemplo melhor ainda. Talvez você discorde da solução do programador, mas 


pelo menos você sabe o que ele estava tentando fazer. 
public void testConcurrentAddWidgets() throws Exception { 


WidgetBuilder widgetBuilder = 
new WidgetBuilder (new Class[]{BoldWidget.class}); 
String text = "'''bold text'''"; 
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ParentWidget parent = 

new BoldWidget (new MockWidgetRoot(), "''/bold text'''"); 
AtomicBoolean failFlag - new AtomicBoolean(); 
failFlag.set(false); 


//Essa e a nossa melhor tentativa para conseguir uma condicao de corrida. 
/[Para isso criamos um grande numero de threads. 
for (int i = 0; i « 25000; i++) ( 

WidgetBuilderThread widgetBuilderThread - 

new WidgetBuilderThread(widgetBuilder, text, parent, 

failFlag); 

Thread thread - new Thread(widgetBuilderThread); 

thread.start(); 

} 

assertEquals(false, failFlag.get()); 
) 


Esclarecimento 


Às vezes é bom traduzir o significado de alguns parámetros ou valores retornados obscuros para 
algo inteligível. De modo geral, é melhor encontrar uma forma de esclarecer tal parámetro ou 
valor retornado por si só, mas quando for parte da biblioteca padrão, ou de um código que não se 
possa alterar, então um comentário esclarecedor pode ser útil. 


public void testCompareTo() throws Exception 

t 
WikiPagePath a = PathParser.parse(“Pagea"); 
WikiPagePath ab = PathParser.parse("PageA.PageB"); 
WikiPagePath b = PathParser.parse("PageB"); 
WikiPagePath aa = PathParser.parse("PageA.PageA"); 
WikiPagePath bb - PathParser.parse("PageB.PageB"); 
WikiPagePath ba = PathParser.parse("PageB.PageA"); 
assertTrue(a.compareTo(a) 0; Ха а 
assertTrue(a.compareTo(b) 0); //a b 
assertTrue(ab.compareTo (ab) 0); // ab = 
assertTrue(a.compareTo(b) == -1); // a < b 
assertTrue(aa.compareTo(ab) -1); // aa « ab 
assertTrue(ba.compareTo(bb) -1); // ba « bb 


ab 


assertTrue(b.compareTo(a) == 1); // b > a 
assertTrue(ab.compareTo(aa) 1); // ab > аа 
assertTrue(bb.compareTo(ba) == 1); // bb > ba 


) 


Há um risco considerável, é claro, de que um comentário esclarecedor possa estar incorreto. Leia 
o exemplo anterior e veja como é difícil verificar se estão corretos. Isso explica tanto o porquê da 
necessidade do esclarecimento como seu risco. Portanto, antes de criar comentários como esses, 
certifique-se de que não há outra saída melhor e, então, certifique-se ainda mais se estão precisos. 
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Alerta Sobre Consequéncias 


As vezes é util alertar outros programadores sobre certas 
consequências. Por exemplo, o comentário abaixo explica 
porque um caso de teste em particular está desabilitado: 


// NãoNão execute a menos que você 
// tenha tempo disponível. 


public void _testWithReallyBigFile() 

{ 
writeLinesToFile(10000000); 
response.setBody(testFile); 
response.readyToSend(this); 
String responseString - output. 

toString(); 
assertSubString("Content-Length: 1000000000*, responseString); 
assertTrue(bytesSent » 1000000000); 


) 


Hoje em dia, desabilitariamos o teste de caso através do atributo @ignore com uma string 
explanatória adequada: @ignore (“Leva muito tempo para executar”). Antes da chegada do JUnit4, 
uma convencáo comum era colocar um trago inferior (underscore) no início do nome do método. 

O comentário, enquanto divertido, passa sua mensagem muito bem. 

Outro exemplo mais direto seria: 


public static SimpleDateFormat makeStandardHttpDateFormat() 
{ 
//SimpleDateFormat não é uma thread segura, 
//é preciso criar cada instância independentemente. 
SimpleDateFormat df = new SimpleDateFormat("EEE, dd MMM yyyy 
HH:mm:ss 2"); 
df.setTimeZone(TimeZone.getTimeZone("GMT")); 
return df; 
) 


Talvez vocé reclame por haver melhores maneiras de resolver esse problema. Talvez eu 
concorde com vocé, mas o comentário como foi feito é perfeitamente lógico. Ele evitará que um 
programador afoito use um inicializador estático em prol da eficiéncia. 


Comentário TODO " 


Às vezes é cabível deixar notas “To Do” (‘Fazer’) em comentários no formato / /TODO. No caso 
a seguir, o comentário TODO explica por que a função tem uma implementação degradante e o 
que se deveria fazer com aquela função. 


///'TODO-MdM essas não são necessárias 
// Esperamos que isso não esteja mais aqui quando verificarmos o modelo 
protected VersionInfo makeVersion() throws Exception 
t 
return null; 
) 
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TODOS são tarefas que os programadores acham que devem ser efetuadas, mas, por alguma 
razão, não podem no momento. Pode ser um lembrete para excluir uma instrução desnecessária 
ou um apelo para que alguém olhe o problema. Ou um pedido para que alguém pense em um nome 
melhor ou um lembrete para fazer uma alteração que é dependente de um evento determinado. 
Seja qual for o TODO, ele não justifica deixar um código ruim no sistema. 

Hoje em dia, a maioria das IDEs oferecem ferramentas e recursos para localizar todos os 
comentários TODO; portanto. não é provável que fiquem perdidos no código. Mesmo assim, você 
não deseja que seu código fique amontoado de TODOS, sendo assim, procure-os regularmente e 
elimine os que puder. 


Destaque 


Pode-se usar um comentário para destacar a importância de algo que talvez pareça irrelevante. 


String listItemContent = match.group(3).trim(); 

// a função trim é muito importante. Ela remove os espaços 
// iniciais que poderiam fazer com que o item fosse 

44 reconhecido como outra lista. 

new ListItemWidget(this, listItemContent, this.level + 1); 
return buildList(text.substring(match.end())); 


Javadocs em APIs Püblicas 


Não há nada de tão prático e satisfatório como uma API pública em descrita. Os javadocs para a 
biblioteca Java padrão são um exemplo. No máximo, seria dificil escrever programas Java sem eles. 

Se estiver criando uma API pública, então você certamente deveria escrever bons javadocs 
para ela. Mas tenha em mente os outros conselhos neste capítulo. Os javadocs podem ser tão 
enganadores, não-locais e desonestos como qualquer outro tipo de comentário. 


Comentários Ruins 


A maioria dos comentários cai nesta categoria. Geralmente eles são suportes ou desculpas para 
um código de baixa qualidade ou justificativas para a falta de decisões, amontoados como se o 
programador estivesse falando com si mesmo. 


Murmirio ^ 


Usar um comentário só porque vocé sente que deve ou porque o processo o requer é besteira. Se 
optar criar um comentário, então gaste o tempo necessário para fazé-lo bem. 

Por exemplo, a seguir está um caso que encontrei no FitNesse, no qual um comentário poderia 
ter sido útil. Entretanto, o autor estava com pressa ou não prestava muita atenção. Seu murmürio 
foi deixado para trás como um enigma: 


public void loadProperties() 
t 
try 
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String propertiesPath = 
propertiesLocation + “/” + PROPERTIES FILE; 
FileInputStream propertiesStream = 
new FileInputStream(propertiesPath); 
loadedProperties.load(propertiesStream); 
) 
catch(IOException e) 
{ 
// Nenhum arquivo de propriedades significa que todos os padrões 
estão carregados 
) 
) 


O que esse comentário no bloco catch significa? Claramente fazia sentido para o autor, 
mas o significado nào foi muito bem transmitido. Aparentemente, se capturarmos (catch) uma 
IOException, significaria que não há arquivo de propriedades; e, neste caso, todos os padrões 
estão carregados. Mas quem carrega os padrões? Eles foram carregados antes da chamada ao 
loadProperties.1oad? Ou este capturou a exceção, carregou os padrões e, então, passou a 
exceção para que ignorássemos? Ou loadProperties. load carregou todos os padrões antes 
de tentar carregar o arquivo? Será que o autor estava limpando sua consciência por ter deixado 
o bloco do catch vazio? Ou — e essa possibilidade é assustadora — ele estava tentando dizer a si 
mesmo para voltar depois e escrever o código que carregaria os padrões? 

Nosso único recurso é examinar o código em outras partes do sistema para descobrir o que 
está acontecendo. Qualquer comentário que lhe obrigue a analisar outro módulo em busca de um 
significado falhou em transmitir sua mensagem e não vale os bits que consume. 


Comentários Redundantes 


A Listagem 4.1 uma função simples com um comentário no cabeçalho que é completamente 
redundante. Provavelmente leva-se mais tempo para lê-lo do que o código em si. 


Listagem 4-1 
waitForClose 


// Utility method that returns when this.closed is true. Throws an exception 
// if the timeout is reached. 

public synchronized void waitForClose(final long timeoutMillis) 

throws Exception 


if(!closed) 
{ 
wait (timeoutMillis); 
ifí!closed) 
throw new Exception (“MockResponsesender could not be closed"); 


Qual o propósito desse comentário? Certamente não é mais informativo do que o código. 
Nem mesmo justifica o código ou oferece uma intenção ou raciocínio. E mais fácil ler o código 
apenas. De fato, ele é menos preciso do que o código e induz o leitor a aceitar tal falta de precisão 
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em vez da interpretação verdadeira. É mais como um vendedor interesseiro de carros usados lhe 
garantindo que não é preciso olhar sob o capô. 

Agora considere o grande número de javadocs inúteis e redundantes na Listagem 4.2 retirada 
do Tomcat. Esses comentários só servem para amontoar e encobrir o código. Eles nào passam 
informação alguma. Para piorar, só lhe mostrei os primeiros, mas há muito mais neste módulo. 


Listagem 4-2 ~] 
ContainerBa: 


java (Tomcat) 


public abstract class ContainerBase 
implements Container, Lifecycle, Pipeline, 
MBeanRegistration, Serializable ( 


* The processor delay for this component. 


protected int backaroundProcessorDelay = 


+ The lifecycle event support for this component. 
protected Lifecyclesupport lifecycle = 
new LifecycleSupport (this) ; 


* The container event listeners for this Container. 
*/ 
protected ArrayList listeners = new ArrayList (); 


jae 


* The Loader implementation with which chis Container 
* associated. 
*/ 


protected Loader loader = null; 


* The Logger implementation with which this Container is 


* associated. 
Ш 


protected Log logger = null; 


* Associated logger name. 


protected String logName = null; 


z 


* The Manager implementation with which this Container is 
* associated. 


protected Manager manager - null; 
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Listagem 4-2 (continuação): 
ContainerBase.java (Tomcat) 


Em 
* The cluster with which this Container is associated. 
#4 

protected Cluster cluster = null; 


* The human-readable name of this Container. 


protected String name - null; 


* The parent Container to which this Container is a child. 


protected Container parent - null; 


* The parent class ioader to be c 
* Loader. 


protected ClassLoader parentClassLoad 


nfigured when we install a 


null; 


* The Pipeline object with which this Container is 
* associated. 


protected Pipeline pipeline - new StandardPipeline(this); 


* The Realm with which this Container is associated. 


protected Realm realm - null; 


* The resources DirContext object with which this Container 
* is associated. 


protected DirContext resources - null; 
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Comentários Enganadores 


Às vezes, com todas as melhores das intenções, um programador faz uma afirmação não muito 
clara em seus comentários. Lembre-se também do redundante e enganador comentário que vimos 
na Listagem 4.1. 

Como você descobriu que o comentário era enganador? O método não retornava quando this. 
closed virava true (verdadeiro), mas só se this.closed já fosse true (verdadeiro); 
caso contrário, ele esperava por um tempo limite e, então, lançava uma exceção se this .closed 
ainda não fosse true (verdadeiro). 

Essa pequena desinformação, expressada em um comentário mais difícil de ler do que o código em 
si, poderia fazer com que outro programador despreocupadamente chamasse essa função esperando-a 
que retornasse assim que this closed se tomasse true (verdadeiro) . Esse pobre programador 
logo se veria efetuando uma depuração tentando descobrir o porquê da lentidão do código. 


Comentários Imperativos 


É basicamente tolo ter uma regra dizendo que toda função deva ter um Javadoc, ou toda variável 
um comentário. Estes podem se amontoar no código, disseminar mentiras e gerar confusão e 
desorganização. 

Por exemplo, os javadocs exigidos para cada função levariam a abominações, como as da 
Listagem 4.3. Essa zona não acrescenta nada e só serve para ofuscar o código e abrir o caminho 
para mentiras e desinformações. 


Listagem 4-3 
* param title The title of the CD 
* @param author The author cf the CD 


@param tracks The number of tracks on the CD 

* üparam durationInMinutes The duration of the CD in minutes 
public void addCD(String title, String author, 

int tracks, int durationInMinutes) ( 


ion: 


Comentários Longos 


Às vezes, as pessoas, toda vez que editam um módulo, sempre adicionam um comentário no 
início. Após várias alterações, a quantidade de comentários acumulada parece mais uma redação 
ou um diário. Já vi módulos com dezenas de páginas assim. 
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Ы -Oct-2001) 

+ : Re-organised the class and moved it to new package 

* com.jrefinery.date (DG); 

* 05-Nov-2001 : Added a getDescription() method, and eliminated NotableDate 
a class (DG); 

* 12-Nov-2001 : IBD requires setDescriptioni) method, now that NotableDate 
* class is gone (DG); Changed getPreviousDayOfWeek i), 

+ getFollowingDayOfWeeki) and getNearestDay0fWeek() to correct 
ba bugs (DG); 
* 

+ 


05-Dec-2001 : Fixed bug in SpreadsheetDate class (DG): 
29-May-2002 : Moved the month constants into a separate interface 
(MonthConstants) (DG); 

Fixed bug in addMonths() method, thanks to Nº 
: Fixed errors reported by Checkstyle (DG); 
Implemented Serializable (DG); 

Fixed bug in addMonths method (DG) 
Implemented Comparable. Updated the isInRange javadocs (DG); 
Fixed bug in addYears() method (1096282) (DG); 


27-Aug-2002 
93-Oct-2002 
13-Mar-2003 


levka Petr (DG); 


-May-2003 
04-Sep-2003 
05-Jan-2005 : 


Há muito tempo, havia um bom motivo para criar e preservar essas informações no início de 
cada módulo, pois não existiam ainda os sistemas de controle de código fonte para fazer isso por 
nós. Hoje em dia, entretanto, esses comentários extensos são apenas entulhos que confundem o 
código. devendo assim ser completamente removidos. 


Comentários Ruidosos 


Às vezes você vê comentários que nada são além de “chiados”. Eles dizem o óbvio e não 
fornecem novas informações. 


je 
* Construtor padráo 
"f 
protected AnnualDateRule() ( 
} 


Ah, sério? Ou este: 


/** Dia do mes. */ 
private int dayOfMonth; 


E há também o seguinte tipo de redundáncia: 
qux Е 


* Retorna do dia do mês. 
* @return o dia do més. 
37, т 
public int getDayOfMonth() ( 
return dayOfMonth; 
) 


Esses comentários são tão irrelevantes que aprendemos a ignorá-los. Ao lermos o código, nossos 
olhos passam direto por eles. No final, os comentários passam a “mentir” conforme o código muda. 
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O primeiro comentário na Listagem 4.4 parece adequado”. Ele explica por que o block catch 
é ignorado. Contudo, o segundo não passa de um chiado. Aparentemente, o programador estava 
tão frustrado por criar blocos try/catch na função que ele precisou desabafar. 


|8 Listagem 4-4 
startSending 


private void startSending() 


try 


i 


) 
catch(SocketException e) 
{ 


doSending(); 


// normal. someone stopped the request. 
} 
catch(Exception e) 
try 
t 
response.add (ErrorResponder .makeExceptionstring(e) ); 
response.closeAlli); 
1 
catch(Exception el) 


//Give me a break! 


Em vez de desabafar em comentários sem sentido e ruidosos, ele poderia ter pegado tal 
frustração c usado-a para melhorar a estrutura do código. Ele deveria ter redirecionado sua energia 
para colocar o último bloco try/catch em uma função separada, como mostra a Listagem 4.5. 


Listagem 4-5 
startSending (refatorado) 


private void startSending() 
{ 
try 


doSending!) ; 


atch (SocketException e) 


i| normal. someone stopped the request. 


catch{Exception е) 


——_ 


2 A tendência atual das IDEs de verificação da ortografia em comentários será um alivio para nós que lemos bastante códigos. 
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Listagem 4-5 (continuação) 
startSending (refatorado) 


addExceptionandCloseResponse (е): 
H 


private void addExceptionAndCloseResponse (Exception e) 
{ 


ту 


response. add (Er 


Responder .makeExcept ionString(e]); 
response.closeallt); 


atch (Exception е1) 


Eve 


Troque a tentação para criar ruídos pela determinação para limpar seu código. Você perceberá 
que isso lhe tornará um programador melhor e mais feliz. 


Ruídos assustadores 


Os javadocs também podem ser vistos como ruídos. Qual o objetivo dos Javadocs (de uma 
biblioteca de código livre bem conhecida) abaixo? 


/** Nome. */ 
private String name; 


/** The version. */ 
private String version; 


/** Nome da licenca. */ 
private String licenceName; 


/** Versão. */ 
private String info; 


Releia os comentários com mais atenção. Notou um erro de recortar-colar? Se os autores nào 
prestarem atenção na hora de escrever os comentários (ou colá-los), por que os leitores deveriam 
esperar algo de importante deles? 


Evite o comentário se é possível usar uma função ou uma variável 


Considere o pedaço de código abaixo: 


// o módulo da lista global «mod» depende do 
// subsistema do qual fazemos parte? 
if (smodule.getDependSubsystems().contains(subSysMod.getSubSystem())) 
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Poderia-se evitar o comentário e usar: 


ArrayList moduleDependees = smodule.getDependsubsystems(); 
String ourSubSystem = subSysMod.getSubSystem(); 
if (moduleDependees.contains(ourSubSystem)) 


O autor do código original talvez tenha escrito primeiro o comentário (pouco provável) e, então, 
o código de modo a satisfazer o comentário. Entretanto, o autor deveria ter refatorado o código, 
como eu fiz, para que pudesse remover o comentário. 


Marcadores de Posição 


Algumas vezes os programadores gostam de marcar uma posição determinada no arquivo fonte. 
Por exemplo, recentemente encontrei o seguinte num programa: 


// ações ////////////////////////////////// 


É raro, mas há vezes que faz sentido juntar certas funções sob um indicador como esses. Mas, de 
modo geral, eles são aglomerações e devem-se exclui-los—especialmente as várias barras no final. 

Pense assim: um indicador é chamativo e óbvio se você não os vê muito frequentemente. 
Portanto, use-os esporadicamente, e só quando gerarem benefícios significativos. Se usar 
indicadores excessivamente, eles cairão na categoria de ruídos e serão ignorados. 


Comentários ao lado de chaves de fechamento 

Às vezes. os programadores colocam comentários especiais ao lado de chaves de fechamento, 
como na Listagem 4.6. 

Embora isso possa fazer sentido em funções longas com estruturas muito aninhadas, só serve para 
amontoar o tipo de funções pequenas e encapsuladas que preferimos. Portanto, se perceber uma 
vontade de comentar ao lado de chaves de fechamento, tente primeiro reduzir suas funções. 


Listagem 4-6 
ava 


public class wc { 
public static void main(String[] args) { 
BufferedReader new BufferedReader (new InputStreamReader (System.in}); 
String line; 
int lineCount 
int charCount 
int wordCount 
try l 


0; 


е 


while ((line = in.readLine()) != null) ( 
lineCount+ 
charCount += line. length(); 
tring words{] = line.split( i 
wordCount += words. length; 

) //while 


System.out .printin('wordCounz 

System.out.println('lineCount 

System.out.println(*charCount - 
) // try 


* + wordCount) ; 
* + lineCount) ; 
* + charCount) ; 
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Listagem 4-6 (continuação) 
wc.java 


catch (IOException e) ( 
System.err.println("Error:' + e.getMessage()}; 
) //catch 
) //main 
} 


Créditos e autoria 
/* Adicionado por Rick */ 


Os sistemas de controle de código fonte são muito bons para lembrar que adicionou o quê e 
quando. Não há necessidade de poluir o código com comentários de autoria. Talvez você ache 
que tais comentários sejam úteis para ajudar outras pessoas a saberem o que falar sobre o código. 
Mas a verdade é que eles permanecem por anos, ficando cada vez menos precisos e relevantes. 

Novamente, o sistema de controle de código fonte é um local melhor para este tipo de 
informação. 


Explicação do código em comentários 


Poucas práticas são tão condenáveis quanto explicar o código nos comentários. Não faça isso! 


InputStreamResponse response = new InputStreamResponse(); 
response.setBody(formatter.getResultStream(),formatter. 
getByteCount()); 

// InputStream resultsStream = formatter.getResultStream(); 
// StreamReader reader = new StreamReader(resultsStream); 

// respons: 'tContent(reader.read(formatter.getByteCount())); 


Outros que vissem esse código não teriam coragem de excluir os comentários. Eles achariam que 
estão lá por um motivo e são importantes demais para serem apagados. Portanto, explicação de 
códigos em comentários se acumula como sujeira no fundo de uma garrafa de vinho ruim. 
Observe o código do Commons do Apache: 


this.bytePos = writeBytes(pngIdBytes, 0); 
//hárPos = bytePos; 
writeHeader(); 
writeResolution(); 
//dataPos = bytePos; 
if (writeImageData()) ( 
writeEnd(); 
this.pngBytes = resizeByteArray(this.pngBytes, this.maxPos); 
) 
else { 
this.pngBytes - null; 


return this.pngBytes; 
Por que aquelas duas linhas de código estào comentadas? Elas sào importantes? Foram deixados 


como lembretes para alguma alteração iminente? Ou são apenas aglomerados que alguém 
comentara anos atrás e simplesmente não se preocupou em limpar? 
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Houve uma época, na década de 1960, em que explicar o código em comentários poderia ser 
prático. Mas já faz um tempo que temos os sistemas de controle de código fonte, que lembrarão 
o código para nós. Não precisamos explicá-lo em comentários. Simplesmente exclua o código. 
Prometo que não o perderá. 


Comentários HTML 


Códigos HTML em comentários de código fonte são uma aberração, como pode ver no código 
abaixo. Eles dificultam a leitura dos comentários onde seriam fáceis de ler — no editor/IDE. Se 
forem extrair comentários com alguma ferramenta (como o Javadoc) para exibir numa página da 
Web, então deveria ser responsabilidade de tal ferramenta, e não do programador, adicionar os 
comentários com os códigos HTML adequados. 


jee 


Tarefa para executar os testes do Fit, 

Essa tarefa efetua os testes do FitNesse e exibe os resultados. 
<p/> 

<pre> 

Uso: 

&lt;taskdef name=&quot;execute-fitnesse-tests&quot; 
classname=&quot ;fitnesse.ant .ExecuteFitnesseTestsTask&quot; 
classpathref-&quot;classpath&quot; /&gt; 


ou 

&lt;taskdef classpathref-&quot;classpath&quot; 
resource-&quot;tasks.properties&quot; /&gt; 
<p/> 

&lt;execute-fitnesse-tests 

suitepage=&quot ;FitNesse.SuiteAcceptanceTests&quot; 
&quot;8082&quot; 

quot; ${results.dir}&quot; 
resultshtmlpage=équot;fit-results.html&quot; 
classpathref=&quot;classpath&quot; /&gt; 
</pre> 


ROGO OG A o od 


«f 
Informacóes náo-locais 


Se você precisar escrever um comentário, então, coloque-o perto do código que ele descreve. Não 
forneça informações gerais do sistema no contexto de um comentário local. Considere, por exemplo. 
o comentário do Javadoc abaixo. Além de ser terrivelmente redundante, ele também fala sobre a 
porta padrão. Ainda assim, a função nem sabe que porta é essa. O comentário não está descrevendo 
a função, mas alguma outra em alguma parte distante do sistema. Certamente não há garantia de 
que esse comentário será atualizado quando o código que contém tal padrão for alterado. 
yee 
* Porta na qual o FitNesse deveria rodar. Padrão para <b>8082</b>. 
* @param fitnessePort 
AT 
public void setFitnessePort(int fitnessePort) 


this.fitnessePort - fitnessePort; 
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Informacóes excessivas 


Não adicione discussões históricas interessantes ou descrições irrelevantes de detalhes em seus 
comentários. Abaixo está o comentário de um módulo projetado para testar se uma função 
poderia codificar e decodificar base64. Além do número RFC, a pessoa que ler este código nào 
precisa das informações históricas contidas no comentário. 


" 
RFC 2045 - Multipurpose Internet Mail Extensions (MIME) 

Parte um: seção 6.8 do Formato dos Corpos de Mensagens da Internet. 
Codificação e Transferencia de Conteúdo em Base64 

O processo de codificação representa grupos de entrada de 24 bits 
como strings de saída de 4 caracteres codificados. Da esquerda para 
a direita, forma-se um grupo de entrada de 24 bits pela concatenação 
de 3 grupos de entrada de 8 bits. 

Esses 24 bits serão, então, tratados como 4 grupos concatenados 

de 6 bits, cada um traduzido para um único digito do alfabeto da 
base64. Ao codificar um fluxo de bits através da codificação para 
base64, deve-se presumir que tal fluxo esteja ordenado com o bit mais 
significante vindo primeiro. 

Ou seja, o primeiro bit no fluxo será o mais relevante no primeiro 
byte de 

8 bits, o oitavo será o bit menos relevante no mesmo primeiro byte 
de 8 bits, 

e assim por diante. 

" 


Conexóes nada óbvias 


A conexão entre um comentário e o código que ele descreve deve ser óbvia. Se for fazer um 
comentário, então você deseja, pelo menos, que o leitor seja capaz de ler o comentário e o código 
e, então, entender o que foi falado. 
Considere, por exemplo, o comentário abaixo do Commons do Apache: 
z 
* começa com um array grande o bastante para conter todos os 
pixels 
* (mais os bytes de filtragem) e 200 bytes extras para informações 
no cabeçalho 
i À 
this.pngBytes = new byte[((this.width + 1) * this.height * 3) + 200]; 


O que é um byte de filtragem? Ele tem a ver com o +1? Ou com o *3? Com ambos? Um pixel 
é um byte? Por que 200? O objetivo de um comentário é explicar o que o código não consegue 
por si só. É uma lástima quando um comentário também precisa ser explicado. 


Cabeçalhos de funções 


Funções curtas não requerem muita explicação. Um nome bem selecionado para uma função 
pequena que faça apenas uma coisa costuma ser melhor do que um comentário no cabeçalho. 
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Javadocs em códigos não-públicos 


Assim como os Javadocs são práticos para as APIs públicas. eles são uma maldição para o 
código não voltado para a distribuição ao público. Gerar páginas Javadoc para classes e funções 
dentro de um sistema geralmente não é prático, e a formalidade extra dos comentários javadocs 
unem um pouco mais de entulhos e distração. 


Exemplo 


Na Listagem 4.7, criei um módulo para o primeiro XP /mmersion para servir de exemplo de má 
programação e estilo de comentário, Então, Kent Beck refatorou esse código para uma forma muito 
mais agradável na presença de algumas dezenas de estudantes empolgados. Mais tarde, adaptei o 
exemplo para meu livro Agile Sofiware Development, Principles, Patterns, and Practices e o 
primeiro de meus artigos da coluna Craftsman publicados na revista Software Development. 

Para mim, o fascinante desse módulo é que havia uma época quando muitos de nós o teríamos 
considerado “bem documentado”. Agora o vemos como uma pequena bagunça. Veja quantos 
problemas diferentes você consegue encontrar. 


Listagem 4-7 
GeneratePrimes. java 


This class Generates prime numbers up to a user specified 
maximum. The algorithm used is the Sieve of Eratosthenes. 
<p> 

Eratosthenes of Cyrene, b. c. 276 BC, Cyrene, Libya - 

d. c. 194, Alexandria. The first man to calculate the 
circumference of the Earth. Also known for wo: 
calendars with leap years and ran the library al 
<p> 

The algorithm is quite simple. Given an array of integers 
Starting at 2. Cross cut all multiples of Find the next 
uncrossed integer, and cross out all of its multiples 
Repeat untilyou have passed the square root of the maximum 
value. 


@author Alphonse 
@version 13 Feb 2002 atp 


заннан жя ee 


import java.u 


il.*; 


public class GeneratePrimes 
( 
* Gparam maxValue is the generation limit 
*/ 
public static int[] generátePrines (int maxValue 
1 


if (maxValue >= 2) // the only valid case 


int s = maxValue + 1; // size of array 
boolean[] f = new boolean[s]: 
int i; 
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Listagem 4-7 (continuação) 
GeneratePrimes. java 


if initialize array to true. 
for (i = 0; i < 5; im) 
f[i] = true; 


| get rid of known non-primes 
f[0] = fil] = false: 


if sieve 
int j; 
for {i = 2; i < Math.sqrtis) + 1; i++) 


{ 
if (f(i]) // if i is uncrossed, cross its multiples. 


for }=2”1;]<в; j += i) 
#0 = 


false; // multiple is not prime 


if (fiil) 
count++; // bump count. 


return primes: / return the primes 
} 


else // maxvalue < 2 
return new int[0]; // return null array if bad input. 


Na Listagem 4.8 pode-se ver uma versão refatorada do mesmo módulo. Note que o uso de 


comentários foi limitado de forma significativa — há apenas dois no módulo inteiro, e ambos são 
auto-explicativos. 


Listagem 4.8: 
PrimeGenerator.java (refatorado) 


jee 


* This class Generates prime numbers up to a user specified 
* maximum. The algorithm used is the Sieve of Eratosthenes 
* Given an array of integers starting at 2: 

1 * Find the first uncrossed integer, and cross out all its 
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Listagem 4-8 (continuação) 
PrimeGenerator java (refatorado) 


* multiples. Repeat until there are no more multiples 
* in the array. 


public class PrimeGenerator 
t 


boolean[] crossedOut; 
int[] result; 


private stat 
private stat. 


public static int[] generatePrimesiint maxValue) 


if (maxValue « 2) 
return new inc[0]; 

else 

{ 
uncrossIntegersUpTo imaxValue) ; 
crossOutMultiples і): 
putUncrossedintegersIntoResult () ; 
return result; 


} 


private static void uncrossIntegersUpToiint maxValue) 
crossedOut = new boolean[maxValue + 1] 


for (int i = 2; i « crossedOut.length; i++) 
crossedOut(i] = false; 


H 


private static void crossOutMultiples() 
I 
int limit = determineIterationLimit (); 
for lint i = i <= limit; i++) 
if (notCrossed(i)) 
crossOutMult iplesOf (i); 


} 


private static int determineIterationLimit() 


// Every multiple in the array has a prime factor that 
/ is less than or equal tc the root of the array size, 
/ во we don't have to cross out multiples oi numbers 
// larger than that root. 

double iterationLimit = Math. sqrt (crossedOut . length) ; 
return (int) iterationLimit; 


private static void crossOutMultiplesOf(int ij 


for (int multiple = 2*i; 
multiple < crossedOut.length; 
multiple += i) 

crossedout [multiple] = true; 
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Listagem 4-8 (continuação) 
PrimeGenerator java (refatorado) 


private static boolean notCrossedtint i) 
{ 

return crossedout [i] == false; 
) 


private static void putUncrossedIntegersIntoResult () 


result = new int|[numberOfUncrossedIntegers ()] ; 
for (int j = 0, i = 2; i < crossedQut.lenath; i++) 
if (notCrossed(i)) 


result(j++] = i; 


) 


private static int numberOfUncrossedIntegers |) 
{ 


int count = 0; 


for (int i = 2; i < crossedout length; i++) 
if (notCrossed(ij) 
count++; 


return count; 
! 


} 


Como o primeiro comentário é muito parecido com a função generatePrimes, fica fácil dizer 
que ele é redundante. Mesmo assim, acho que o comentário serve para facilitar a leitura do 
algoritmo, portanto prefiro mantê-lo. 

Já o segundo se faz praticamente necessário. Ele explica a lógica por trás do uso da raiz 
quadrada como o limite da iteração. Não consegui encontrar um nome simples para a variável 
ou qualquer estrutura diferente de programação que esclarecesse esse ponto. Por outro lado, 
o uso da raiz quadrada poderia ser um conceito. Realmente estou economizando tanto tempo 
assim ao limitar a iteração à raiz quadrada? O cálculo desta demora mais do que o tempo que 
economizo? 

Vale a pena ponderar. Usar a raiz quadrada como o limite da iteração satisfaz o hacker em 
mim que usa a antiga linguagem C e Assembly, mas nào estou convencido de que compense o 
tempo e o esforço que todos gastariam para entendê-la. 


Bibliografia 


[KP78]: Kernighan and Plaugher. The Elements of Programming Style, 2d. ed., McGraw- 
Hill, 1978. 


5 


Formatação 


Quando as pessoas olham o código. desejamos que fiquem impressionadas com a polidez, a 
consistência e a atenção aos detalhes presentes. Queremos que reparem na organização. 
Desejamos que suas sobrancelhas se levantem ao percorrerem os módulos; que percebam que 
foram profissionais que estiveram ali. Se, em vez disso, virem um emaranhado de código como 
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se tivesse sido escrito por um bando de marinheiros bêbados, então provavelmente concluirão 
que essa mesma falta de atenção foi perpetuada por todo o projeto. 

Você deve tomar conta para que seu código fique bem formatado, escolher uma série de regras 
simples que governem seu código e, então, aplicá-la de forma consistente. Se estiver trabalhando 
em equipe. então, todos devem concordar com uma única série de regras de formatação. Seria 
bom ter uma ferramenta automatizada que possa aplicar essas regras para você. 


O objetivo da formatação 


Primeiro de tudo, sejamos claros. A formatação do código é importante. Importante demais para 
se ignorar e importante demais para ser tratada religiosamente. Ela serve como uma comunicação, 
e essa é a primeira regra nos negócios de um desenvolvedor profissional. 

Talvez você pensasse que “fazer funcionar” fosse a primeira regra. Espero, contudo, que, a 
esta altura, este livro já tenha tirado esse conceito de sua mente. A funcionalidade que você cria 
hoje tem grandes chances de ser modificada na próxima distribuição, mas a legibilidade de seu 
código terá um grande efeito em todas as mudanças que serão feitas. A formatação do código 
e a legibilidade anteriores que continuam a afetar a capacidade de extensão e de manutenção 
tempos após o código original foram alteradas além de reconhecimento. Seu estilo e disciplina 
sobrevivem, mesmo que seu código não. 

Então quais as questões sobre formatação que nos ajuda a comunicar melhor? 


Formatação vertical 


Comecemos com o tamanho vertical. O seu código-fonte deve ser de que tamanho? Em Java, o 
tamanho do arquivo está intimamente relacionado ao da classe. Discutiremos sobre o tamanho das 
classes quando falarmos sobre classes. Mas, por agora, consideremos apenas o tamanho do arquivo. 

Qual o tamanho da maioria dos códigos-fonte em Java? Há uma grande diversidade de 
tamanhos e algumas diferenças notáveis em estilo (veja a Figura 5.1). Há sete projetos diferentes 
na figura: Junit, FitNesse, testNG, Time and Money, JDepend, Ant e Tomcat. As linhas verticais 
mostram os comprimentos mínimo e máximo em cada projeto. A caixa exibe aproximadamente 
um terço (um desvio padrão") dos arquivos. O meio da caixa é a média. Portanto, o tamanho 
médio do código no projeto FitNesse é de cerca de 65 linhas, e cerca de um terço dos arquivos 
estão entre 40 e 100+ linhas. O maior arquivo no FitNesse tem aproximadamente 400 linhas, e 
o menor 6. 

Note que essa é uma escala logaritmica; portanto, a pequena diferença na posição vertical 
indica uma diferença muito grande para o tamanho absoluto. 

Junit, FitNesse e Time and Money são compostos de arquivos relativamente pequenos. 
Nenhum ultrapassa 500 linhas e a maioria dos arquivos tem menos de 200 linhas. Tomcat e 
Ant, por outro lado, têm alguns arquivos com milhares de linhas e outros, próximos à metade, 
ultrapassam 200 linhas. 

O que isso nos diz? Parece ser possível construir sistemas significativos (о FitNesse tem 
quase 50.000 linhas) a partir de códigos simples de 200 linhas, com um limite máximo de 500. 
Embora essa não deva ser uma regra fixa, deve-se considerá-la bastante, pois arquivos pequenos 
costumam ser mais fáceis de se entender do que os grandes. 


мүсөн е eo o a a a ctn Mon n aÃ 
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A metáfora do jornal 


Pense num artigo de jornal bem redigido. Você o lê verticalmente. No topo você espera ver 
uma manchete que lhe diz do que se trata a estória e lhe permite decidir se deseja ou não ler. o 
primeiro parágrafo apresenta uma sinopse da estória toda, omitindo todos os detalhes, falando de 
uma maneira mais geral. Ao prosseguir a leitura, verticalmente, vão surgindo mais detalhes até 
que datas, nomes, citações, alegações e outras minúcias sejam apresentadas. 

Desejamos que um código fonte seja como um artigo de jornal. O nome deve ser simples 
mas descritivo. O nome em si deve ser o suficiente para nos dizer se estamos no módulo certo ou 
não. As partes mais superiores do código-fonte devem oferecer os conceitos e algoritmos de alto 
nível. Os detalhes devem ir surgindo conforme se move para baixo, até encontrarmos os detalhes 
e as funções de baixo nível no código-fonte. 


10000.0 


1000 


100 


Figura 5.1: 
Escala logarítmica de distribuição de tamanho de arquivos (altura da caixa = sigma) 


Um jornal é composto de muitos artigos: a maioria é bastante pequena. Alguns são um 
pouco maiores. Muito poucos possuem textos que preencham a página toda. Isso torna o jornal 
aproveitável. Se ele fosse apenas uma estória extensa com uma aglomeração desorganizada de 
fatos, datas e nomes, nós simplesmente não o leríamos. 


Espaçamento vertical entre conceitos 


Quase todo código é lido da esquerda para a direita e de cima para baixo. Cada linha representa 
uma expressão ou uma estrutura, e cada grupo de linhas representa um pensamento completo. 
Esses pensamentos devem ficar separados por linhas em branco. 

Considere, por exemplo, a Listagem 5.1. Há linhas em branco que separam a declaraçãoe a 
importação do pacote e cada uma das funções. Essa simples e extrema regra tem grande impacto 
no layout visual do código. Cada linha em branco indica visualmente a separação entre conceitos. 
Ao descer pelo código, seus olhos param na primeira linha após uma em branco. 
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Retirar essas linhas em branco, como na Listagem 5.2, gera um efeito notavelmente obscuro 
na legibilidade do código. 


Listagem 5-2 
Boldwidget . java 


package fitnesse.wikitext widgets; 
import java.util.regex.*: 
public class BoldWidget extends ParentWidget ( 
public static final String REGEXP = *'''.52'''*; 
private static final Pattern pattern = Pattern.compilei"'''(.+7)'''", 
Pattern.MULTILINE + Pattern.DOTALL); 
public BoldWidgetiParentWidget parent, String text) throws Exception ( 
super (parent) ; 
Matcher match = pattern.matcher (text); 
match. find() ; 
addChildwidgets (match.group(1));) 
public String render() throws Exception ( 
StringBuffer html = new StringBuffer ("<b>"); 
html .append (child#tml ()) .append("</b>*") 
return html.toString(); 
} 


} 


Esse efeito é ainda mais realçado quando você desvia seus olhos do código. No primeiro 
exemplo, os diferentes agrupamentos de linhas saltam aos olhos, enquanto no segundo tudo fica 
meio confuso. A diferença entre essas duas listagens é um pouco de espaçamento vertical. 


Continuidade vertical 


Se o espaçamento separa conceitos, então a continuidade vertical indica uma associação intima. 
Assim, linhas de código que estão intimamente relacionadas devem aparecer verticalmente 
unidas. Note como os comentários inúteis na Listagem 5.3 quebram essa intimidade entre a 
instância de duas variáveis. 


Listagem 5.3 
public class ReporterConfig { 


* The class name of the reporter listener 


private String m_className; 
p 


* The properties of the reporter listener 


private List<Property> m properties = new ArrayList<Property>(); 


public void addProperty (Property property) ( 
m properties.add (property); 
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A Listagem 5.4 está muito mais fácil de se ler. Ela cabe numa única visão, pelo menos para 
mim. Posso olhá-la e ver que é uma classe com duas variáveis e um método, sem ter de mover 
muito minha cabeça ou meus olhos. A listagem anterior me faz usar mais o movimento dos olhos 
e da cabeça para obter o mesmo nível de entendimento. 


Listagem 5.4 


public class ReporterConfig ( 
private String m className; 
private List<Property> m properties = new ArrayList«Property»!); 


public void addProperty (Property property) ( 
m properties.add(property) ; 


Distáncia vertical 


Já ficou tentando se encontrar numa classe. passando de uma função para a próxima, subindo e 
descendo pelo código-fonte, tentando adivinhar como as funções se relacionam e operam, só para 
se perder nesse labirinto de confusão? Já subiu pela estrutura de herança buscando a definição de 
uma variável ou função? Isso é frustrante, pois você está tentando entender o que o sistema faz, 
enquanto gasta tempo e energia mental numa tentativa de localizar e lembra onde estão as peças. 

Os conceitos intimamente relacionados devem ficar juntos verticalmente [G10]. 

Obviamente essa regra não funciona para conceitos em arquivos separados. Mas. então, não 
se devem separar em arquivos distintos conceitos intimamente relacionados, a menos que tenha 
uma razão muito boa. Na verdade, esse é um dos motivos por que se devem evitar variáveis 
protegidas. Para os conceitos que são tão intimamente relacionados e que estão no mesmo 
ivo-fonte, a separação vertical deles deve ser uma medida do quão importante eles são para 
ilidade um do outro. Queremos evitar que nossos leitores tenham de ficar visualizando 
vários dos nossos arquivos-fonte e classes. 


Declaração de variáveis. Devem-se declarar as variáveis o mais próximo possível de onde 
serão usadas. 
Como nossas funções são muito pequenas, as variáveis locais devem ficar no topo de cada 


função, como mostra a função razoavelmente longa abaixo do Junit4.3.1. 


private static void readPreferences() ( 
InputStream is= null; 
try ( 
is- new FileInputStream(getPreferencesFile()); 
setPreferences(new Properties(getPreferences())); 
getPreferences().load(is); 
) catch (IOException e) ( 
try ( 
if (is !- null) 
is.close(); 
) catch (IOException el) ( 
) 
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Geralmente, devem-se declarar as variáveis de controle para loops dentro da estrutura de iteração, 
como mostra essa pequenina função da mesma fonte acima. 
public int countTestCases() ( 
int count= 0; 
for (Test each : tests) 
count += each.countTestCases(); 


return count; 
H 


Em raros casos pode-se declarar uma variável no início de um bloco ou logo depois de um 
loop em uma função razoavelmente longa. Veja um exemplo no pedacinho abaixo de uma função 
muito extensa do TestNG. 


for (XmlTest test : m suite.getTests()) ( 
TestRunner tr - m runnerFactory.newTestRunner(this, test); 
tr.addListener(m textReporter); 
m testRunners.add(tr); 


invoker = tr.getInvoker(); 


for (ITestNGMethod m : tr.getBeforeSuiteMethods()) ( 
beforeSuiteMethods.put(m.getMethod(), m); 
} 


for (ITestNGMethod т : tr.getAfterSuiteMethods()) ( 
afterSuiteMethods.put(m.getMethod(), m); 
) 


Instáncias de variáveis. Por outro lado, devem-se declarar as instáncias de variáveis no início da 
classe. Isso nào deve aumentar a distância vertical entre tais variáveis, pois, numa classe bem 
projetada, elas são usadas por muitos, senão todos, os métodos da classe. 

Muito já se discutiu sobre onde devem ficar as instâncias de variáveis. Em C++ é comum a 
regra da tesoura, na qual colocamos todas as instâncias das variáveis no final. Em java, contudo, 
a convenção é colocá-las no início da classe. 

Não vejo motivo para seguir uma ou outra convenção. O importante é que as instâncias de 
variáveis sejam declaradas em um local bem conhecido. Todos devem saber onde buscar as 
declarações. 

Considere, por exemplo, o estranho caso da classe TestSuite no JUnit 4.3.1. Resumi 
bastante essa classe para mostrar a questão. Se você ler até cerca de metade do código, verá 
duas instâncias de variáveis declaradas. Seria difícil ocultá-las num lugar melhor. Quem ler este 
código se depararia por acaso com as declarações (como ocorreu comigo). 


public class TestSuite implements Test ( 
static public Test createTest(Class«? extends TestCase> 
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theclass, 


String name) ( 


) 

public static Constructor<? extends TestCase> 
getTestConstructor(Class«? extends TestCase» theClass) 
throws NoSuchMethodException ( 


H 

public static Test warning(final String message) ( 

} 

private static String exceptionToString(Throwable t) { 


} 
private String fName; 


privi Vector«Test» fTests- new Vector«Test»(10); 


public TestSuite() ( 
) 


public TestSuite(final Class«? extends TestCase» theClass) 


} 


public TestSuite(Class<? extends TestCase> theClass, String 
name) { 


} 


a 


Funções dependentes. Se uma função chama outra, elas devem ficar verticalmente próximas, 
e a que chamar deve ficar acima da que for chamada, se possível. Isso dá um fluxo natural ao 
programa. Se essa convenção for seguida a fim de legibilidade, os leitores poderão confiar que 
as declarações daquelas funções virão logo em seguida após seu uso. Considere, por exemplo, 
o fragmento do FitNesse na Listagem 5.5. Note como a função mais superior chama as outras 
abaixo dela e como elas, por sua vez. chama aquelas abaixo delas também. Isso facilita encontrar 
as funções chamadas e aumenta consideravelmente a legibilidade de todo o módulo. 
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Listagem 5-5 
WikiPageResponder. java 


public class WikiPageResponder implements SecureResponder { 
protected WikiPage page; 
protected PageData pageData; 
protected String pageTitle; 
protected Request request; 
protected PageCrawler crawler; 


public Response makeResponse (FitNesseContext context, Request request) 
throws Exception { 
String pageName = getPageNameOrDefault (request, "FrontPage*); 


loadPage!pageName, context); 
if (page -- null) 
return notFoundResponse (context, request); 
else 
return makePageResponse (context) ; 
) 


private String getPageNameOrDefault(Request request, String defaultPageName) 
{ 


String pageName = request.getResource(); 
if (StringUtil.isBlank(pageName) ) 
pageName = defaultPageName; 


return pageName; 


protected void loadPage(String resource, FitNesseContext context) 
throws Exception { 
WikiPagePath path = PathParser.parse (resource); 
crawler = context.root.getPageCrawlerí]; 
crawler.setDeadEndStrategy (new VirtualEnabledPageCrawler () ] ; 
page = crawler.getPage(context.rcot, path); 
if (page != null) 
pageData = page.getData(}; 


private Response notFoundResponse(FitNesseContext context, Request request) 
throws Exception { 
return new NotFoundResponder () .makeResponse (context, request); 


) 


private SimpleResponse makePageResponse (FitNesseContext context) 
throws Exception ( 
pageTitle = PathParser. render (crawler.getFullPath (page) ) ; 
String html = makeHtml (context); 


mpleResponse response - new SimpleResponse(); 
response. setMaxAae (0) ; 

response. setContent (html) ; 

return response; 
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Além disso, esse fragmento apresenta um bom exemplo de como manter as constantes 
no nível apropriado [G35]. A constante “FrontPage” poderia ter sido colocada na função 
getPageNameOrDefault, mas isso teria ocultado uma constante bem conhecida e esperada em 
uma função de baixo nível. Foi melhor passar tal constante a partir do local no qual ela faz 
sentido para um onde ela realmente é usada. 


Afinidade conceitual. Determinados bits de código 
querem ficar perto de outros bits. Eles possuem uma certa 
afinidade conceitual. Quanto maior essa afinidade, menor 
deve ser a distância vertical entre eles. 

Como vimos, essa afinidade deve basear-se numa 
dependência direta, como uma função chamando outra ou 
uma função usando uma variável. Mas há outras causas 
possíveis de afinidade, que pode ser causada por um grupo 
de funções que efetuam uma operação parecida. Considere 
o pedaço de código abaixo do JUnit 4.3.1: 


public class Assert ( 

static public void assertTrue(String 
message, boolean condition) ( 
if (!condition) 


fail(message); 


} 


static public void assertTrue(boolean condition) { 
assertTrue(null, condition); 
) 


static public void assertFalse(String message, boolean 
condition) ( 
assertTrue(message, !condition); 
) 


static public void assertFalse(boolean condition) ( 
assertFalse(null, condition); 
) 


Essas funções possuem uma afinidade conceitual forte, pois compartilham de uma mesma 
convenção de nomes e efetuam variações de uma mesma tarefa básica. O fato de uma chamar a 
outra é secundário. Mesmo se não o fizessem, ainda iriam querer ficar próximas. 


Ordenação vertical 


De modo geral, desejamos que as chamadas das dependências da função apontem para baixo. 
Isto é, a função chamada deve ficar embaixo da que a chama:. Isso cria um fluxo natural para 
baixo no módulo do código-fonte, de um nível maior para um menor. 

Assim como nos artigos de jornais, esperamos que a maioria dos conceitos venha primeiro. e 
também que seja expressada com uma quantidade mínima de detalhes. Esperamos que os detalhes 
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de baixo nível venham por último. Isso nos permite passar os olhos nos arquivos-fonte e obter 
uma idéia de algumas das primeiras funções, sem ter de mergulhar nos detalhes. A Listagem 5.5 
está organizada dessa forma. Talvez os exemplos da Listagem 15.5 (p. 263) e 3.7 (p. 50) estejam 
ainda melhores. 

Isso é exatamente o oposto de linguagens, como Pascal, C e C++, que exigem a definição das 
funções, ou pelo menos a declaração. antes de serem usadas. 


Formatação horizontal 


Qual deve ser o tamanho de uma linha? Para responder isso, vejamos como ocorre em 
programas comuns. 

Novamente, examinemos sete projetos diferentes. A Figura 5.2 mostra a distribuição do 
comprimento das linhas em todos os sete projetos. A regularidade é impressionante, cada linha 
fica com cerca de 45 caracteres. De fato, todo comprimento de 20 a 60 representa cerca de 1 
por cento do número total de linhas. Isso são 40%! Talvez outros 30 por cento possuam menos 
do que 10 caracteres. Lembre-se de que é uma escala logarítmica, portanto a aparência linear 
do declínio gradual acima de 80 caracteres é realmente muito significante. Os programadores 
claramente preferem linhas curtas. 

Isso sugere que devemos nos esforçar para manter nossas linhas curtas. O antigo limite de 80 
de Hollerith é um pouco arbitrário, e não sou contra linhas com 100 ou mesmo 120 caracteres. 
Mas ultrapassar isso provavelmente é apenas falta de cuidado. 


100.0000% 


10.0000% 


0.0010% 


0.0001% 


Figura 5.2: 
Distribuição da largura da linha em Java 


Eu costumava seguir a regra na qual jamais se deve ter de rolar a tela para a direita. Mas, hoje 
em dia, os monitores estão muito largos para isso, e programadores mais jovens também podem 
diminuir a fonte de modo que 200 caracteres caibam na tela. Não faça isso. Eu, pessoalmente, 
determinei 120 como meu limite. 
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Espacamento e continuidade horizontal 


Usamos o espaço em branco horizontal para associar coisas que estão intimamente relacionadas 
e para desassociar outras fracamente relacionadas. Considere a função seguinte: 


private void measureLine(String line) ( 


lineCount++; 
int linesize line.length(); 
totalChars linesize; 


lineWidthHistogram.addLine(lineSize, lineCount); 
recordWidestLine(lineSize); 
) 


Coloquei os operadores de atribuição entre espaços em branco para destacá-los. As instruções 
de atribuição têm dois elementos principais e distintos: os lados esquerdo e direito. Os espaços 
tornam essa separação óbvia. 

Por outro lado, não coloque espaços entre os nomes das funções e os parênteses de abertura. Isso 
porque a função e seus parâmetros estão intimamente relacionados. Separá-los iria fazer com que 
parecesse que não estão juntos. Eu separo os parâmetros entre parênteses na chamada da função 
para realçar a vírgula e mostrar que eles estão separados. 

Outro uso do espaço em branco é para destacar a prioridade dos operadores. 


public class Quadratic ( 
public static double rootl(double a, double b, double c) t 
double determinant - determinant(a, b, c); 
return (-b + Math.sqrt(determinant)) / (2*a); * 
) 


public static double root2(int a, int b, int c) ( 
double determinant - determinant(a, b, c); 
return (-b - Math.sqrt(determinant)) / (2*a); 
) 


private static double determinant(double a, double b, double c) 
return b*b - 4*a*c; 
) 


Note como é fácil ler as equações. Os fatores não possuem espaços em branco entre eles 
porque eles têm maior prioridade. Os termos são separados por espaços em branco porque a 
adição e a subtração têm menor prioridade. 

Infelizmente, a maioria das ferramentas para reformatação de código não faz essa distinção 
entre operadores e usam o mesmo espaçamento para todos. Portanto, costuma-se perder 
espaçamentos sutis como os acima na hora da reformatação do código. 
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Alinhamento horizontal 


Quando eu era programador em assembly’,eu usava o alinhamento horizontal para realçar certas 
estruturas. Quando comecei a programar em C, C++ e, depois, em Java, continuei a tentar alinhar 
todos os nomes das variáveis numa série de declarações, ou todos os valores numa série de 
instruções de atribuição. Meu código ficava assim: 


public class FitNesseExpediter implements ResponseSender 
|; 
private Socket socket; 
private InputStream input; 
private OutputStream output; 
private Request request; 
private Response response; 
private FitNesseContext context; 
protected long requestParsingTimeLimit; 
private long requestProgress; 
private long requestParsingDeadline; 
private boolean hasError; 


public FitNesseExpediter(Socket s, 


FitNesseContext context) throws Exception 
{ 
this.context = context; 
socket = s; 
input s.getInputStream(); 
output = s.getOutputStream(); 
requestParsingTimeLimit = 10000; 
+ 


Entretanto, descobri que esse tipo de alinhamento não é prático. Ele parece enfatizar as coisas 
erradas c afasta meus olhos do propósito real. Por exemplo, na lista de declarações acima, você 
fica tentado a ler todos os nomes das variáveis sem se preocupar com seus tipos. Da mesma 
forma, na lista de atribuições, você se sente tentado a ler toda a lista de valores, sem se preocupar 
em ver o operador de atribuição. Para piorar as coisas, as ferramentas de reformatação automática 
geralmente eliminam esse tipo de alinhamento. 

Portanto, acabei não fazendo mais esse tipo de coisa. Atualmente. prefiro declarações e 
atribuições não alinhadas, como mostrado abaixo, pois eles destacam uma deficiência importante. 
Se eu tiver listas longas que precisem ser alinhadas, o problema está no tamanho das listas, e 
não na falta de alinhamento. O comprimento da lista de declarações na FitNesseExpediter 
abaixo sugere que essa classe deva ser dividida. 


public class FitNesseExpediter implements Responsesender 
{ 

private Socket socket; 

private InputStream input; 

private OutputStream output; 

private Request request; 
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Quem estou tentanto enganar? Ainda sou um programador em assembly. Pode-se afastar o 
programador da linguagem, mas não se pode afastar a linguagem do programador! 


private Response response; 

private FitNesseContext context; 
protected long requestParsingTimeLimit; 
private long requestProgress; 

private long requestParsingDeadline; 
private boolean hasError; 


public FitNesseExpediter(Socket s, FitNesseContext context) throws 
Exception 
" 
this.context - context; 
socket - S; 
input - s.getInputStream(); 
output = s.getOutputStream(); 
requestParsingTimeLimit - 10000; 
1 


Endentacáo 


Um arquivo-fonte é mais como uma hierarquia do que algo esquematizado. Há informações 
pertinentes ao arquivo como um todo, às classes individuais dentro do arquivo, aos métodos 
dentro das classes, aos blocos dentro dos métodos e, recursivamente, aos blocos dentro de 
blocos. Cada nível dessa hierarquia é um escopo no qual se podem declarar nomes e no qual são 
interpretadas declarações e instruções executáveis. 

A fim de tornar visível a hierarquia desses escopos, endentamos as linhas do código-fonte 
de acordo com sua posição na hierarquia. Instruções no nível do arquivo, como a maioria das* 
declarações de classes, não são endentadas. Métodos dentro de uma classe são endentados 
um nível à direita dela. Implementações do método são implementadas um nível à direita da 
declaração do método. Implementações de blocos são implementadas um nível à direita do bloco 
que as contém, e assim por diante. 

Os programadores dependem bastante desse esquema de endentação. Eles alinham visualmente 
na esquerda as linhas para ver em qual escopo elas estão. Isso lhes permite pular escopos, 
como de implementações de estruturas if e while, que nào são relevantes no momento. Eles 
procuram na esquerda por novas declarações de métodos, novas variáveis e até novas classes. 
Sem a endentação, os programas seriam praticamente ininteligíveis para humanos. 

Considere os programas seguintes sintática e semanticamente idênticos: 


public class FitNesseServer implements SocketServer ( private 


FitNesseContext 

context; public FitNesseServer(FitNesseContext context) ( this.context - 
context; ) public void serve(Socket s) ( serve(s, 10000); ) public void 
serve(Socket s, long requestTimeout) ( try ( FitNesseExpediter sender - 
new 


FitNesseExpediter(s, context); 
sender.setRequestParsingTimeLimit(requestTimeout); sender.start(); ) 
catch(Exception e) ( e.printStackTrace(); ) ) } 
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public class FitNesseServer implements SocketServer ( 
private FitNesseContext context; 


public FitNesseServer(FitNesseContext context) ( 
this.context - context; 


) 


public void serve(Socket s) ( 


serve(s, 10000); 


public void serve(Socket s, long requestTimeout) ( 


try ( 
FitNesseExpediter sender = new FitNesseExpediter(s, 


context); 
sender.setRequestParsingTimeLimit(requestTimeout); 


sender.start(); 
} 
catch (Exception e) { 
e.printStackTrace(); 
J 


) 


Seus olhos conseguem discernir rapidamente a estrutura do arquivo endentado. Quase 
instantaneamente você localiza as variáveis, os construtores, os métodos acessores (leitura e 
escrita, ou setter and getter) e os métodos. Bastam alguns segundos para perceber que se trata 
de um tipo simples de interface pra um socket, com um tempo limite. A versão sem endentação, 
contudo, é praticamente incompreensível sem um estudo mais profundo. 


Ignorando a endentação. Às vezes, ficamos tentados a não usar a endentação em estruturas i £ curtas, 
loops whi 1e pequenos ou funções pequenas. Sempre que não resisto a essa tentação, quase sempre 
acabo voltando e endentando tais partes. Portanto, evito alinhar uniformemente escopos como este: 


public class CommentWidget extends TextWidget 


t 
public static final String REGEXP = "^s[^WWn]*(?:(?: Vn) |\п|\х)?”; 


public CommentWidget(ParentWidget parent, String text){super(parent, 


text);) 
public String render() throws Exception (return ""; ) 


} 


Prefiro expandir e endentar escopos, como este: 


public class CommentWidget extends TextWidget { 
public static final String REGEXP = “*#(*\r\n]*(?:(?:\r\n)|\n|\x)?"; 


public CommentWidget(ParentWidget parent, String text) { 
super(parent, text); 


) 
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public String render() throws Exception ( 
return *”; 
) 
) 


Escopos minüsculos 


De vez em quando, o corpo de uma estrutura while ou for é minúscula, como mostra abaixo. 
Como não gosto disso. procuro evitá-las. Quando isso não for possível, verifico se o corpo da 
estrutura está endentado adequadamente e entre parênteses. Inúmeras vezes já me enganei com 
um ponto-e-vírgula quietinho lá no final de um loop while na mesma linha. A menos que você 
torne esse ponto-e-vírgula visível endentando-o em sua própria linha, fica difícil visualizá-lo. 


while (dis.read(buf, 0, readBufferSize) !- -1) 


Regra de equipes 


O título desse tópico faz um jogo com as 
palavras. Todo programador tem suas regras de 
formatação prediletas, mas se ele for trabalhar 
em equipe, as regras são dela. Uma equipe de 
desenvolvedores deve escolher um único estilo 
de formatação, e, então, todos os membros ew" f 
devem usá-lo. Desejamos que o software tenha 

um estilo consistente. Não queremos que pensem 

que o código foi escrito por um bando de pessoas em desacordo. 
Quando entrei no projeto FitNesse em 2002, sentei com a equipe para escolher um estilo de 
programação. Isso levou 10 minutos. Decidimos onde colocaríamos nossas chaves, o tamanho 
da endentação, como nomearíamos as classes, variáveis e métodos, e assim por diante. Então, 
codificamos essas regras no formatador de código de nossa IDE e ficamos com ela desde então. 
Não eram as regras que eu preferia, mas as que foram decididas pela equipe. E como membro, 
tive seguí-las na hora de programar no projeto FitNesse. 

Lembre-se: um bom sistema de software é composto de uma série de documentos de fácil leitura. 
Eles precisam ter um estilo consistente e sutil. O leitor precisa poder confiar que as formatações 
que ele vir em um arquivo-fonte terão o mesmo significado nos outros. A última coisa que 
queremos é adicionar mais complexidade ao código-fonte programando-o com um monte de 
estilos diferentes. 


Regras de formatação do Uncle Bob 


As regras que uso são muito simples e estão ilustradas no código da Listagem 5.6. 
Considere isso um exemplo de como o código é o melhor documento padrão em programação. 
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Listagem 5-6 
CodeAnalyzer. java 


public class CodeAnalyzer implements JavaFileAnalysis { 
private int lineCount; 
private int maxLineWidth; 
private int widestLineNumber; 
private LineWidthHistogram lineWidthHistogram; 
private int totalChars; 


public CodeAnalyzer() { 
lineWidthHistogram = new LineWidthHistogram(); 


P 


public static List«File» findJavaPiles(File parentDirectory) { 
List«File» files = new ArrayList«File»(!; 
findJavaFiles(parentDirectory, files); 
return files; 

) 


private static void findJavaFiles(File parentDirectory, List<File> files) 
for (File file entDirectory.listFiles()) { 
if (fi etName(} .endswWith(".java")) 
files.add(file) 
else if (file.isDirectory()) 
findJavaFiles(file, files); 


) 
public void analyzeFile(File javaFile) throws Exception | 
BufferedReader br = new BufferedReader inew FileReader (javaFile}); 
String line; 
while ((line = br.readLine()) != null) 
measureLine (line); 
} 


private void measureLine(String line) { 
lineCount++; 


lineWidthHistogram.addLine(lineSize, lineCount); 
recordWidestLine(lineSize); 
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Listagem 5-6 (continuação) 
CodeAnalyzer.java 


private void recordWidestLine(int lineSize) { 
if (lineSize > maxLineWidth) | 
maxLineWidth - lineSize; 
widestLineNumber = iineCount; 
) 
) 


public int getLineCounti) { 
return lineCount; 

public int getMaxLineWidth() ( 
return maxLineWidth; 

) 


public int getWidestLineNumber() { 
return widestLineNumber; 
} 


public LineWidthHistogram getLineWidthHistogram() { 
return lineWidthHistogram; 
} 


public double getMeanLineWidth() ( 
return (double)totalChars/lineCount; 


} 


public int gerMedianLirewidth() { 

Integer[] sortedWidths = getSortedWidths|) ; 

int cumulativeLineCount = 0; 

for (int width : sortedWidths) ( 
cumulativeLineCount += lineCountForWidth (width); 
if (cumulativeLineCount > lineCount/2) 

return width; 
) 


throw new Error(*Cannot get here"); 
n 


private int lineCountForWidth(int width) ( 
return lineWidthHistogram.getLinesforwidth (width) .size(); 
} 


private Integer[] getSortedWidths() { 
Set<Integer> widths = lineWidthHistogram.getWidths(); 
Integer [] sortedWidths = (widths.coArrayinew Integer [0])); 
Arrays.sort (sortedWidths) ; 
return sortedWidths; 

} 


} 


6 


Objetos e Estruturas de Dados 


Há um motivo para declararmos nossas variáveis como privadas. Não queremos que ninguém 
dependa delas. Desejamos ter a liberdade para alterar o tipo ou a implementação, seja por 
capricho ou impulso. Por que, então, tantos programadores adicionam automaticamente métodos 
de acesso (escrita, ou setters, e leitura, ou geffers) em seus objetos, expondo suas variáveis 
privadas como se fossem públicas? 


Abstração de dados 


Considere a diferença entre as listagens 6.1 e 6.2. Ambas representam os dados de um ponto no 
plano cartesiano. Um expõe sua implementação e o outro a esconde completamente. 
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Listagem 6-1 
Caso concreto 


public class Р 
public double 
public double y; 

} 


Listagem 6-2 
Caso abstrato 


public interface Point { 
double getx( 
double getY(); 
void setCartesian (double x, double y); 
double getR(); 
double getTheta() ; 
void setPolar (double r, double theta); 


} 


O belo da Listagem 6.2 é que não há como dizer se a implementação possui coordenadas 
retangulares ou polares. Pode não ser nenhuma! E ainda assim a interface representa de modo 
claro uma estrutura de dados. 

Masela faz mais do que isso. Os métodos exigem uma regra de acesso. Você pode ler as coordenadas 
individuais independentemente, mas deve configurá-las juntas como uma operação atômica. 

A Listagem 6.1, por outro lado, claramente está implementada em coordenadas retangulares, 
e nos obriga a manipulá-las independentemente. Isso expõe a implementação. De fato, ela seria 
exposta mesmo se as variáveis fossem privadas e estivéssemos usando métodos únicos de escrita 
e leitura de variáveis. 

Ocultar a implementação não é só uma questão de colocar uma camada de funções entre 
as variáveis. É uma questão de ! Uma classe não passa suas variáveis simplesmente por meio 
de métodos de escrita e leitura. Em vez disso, ela expõe interfaces abstratas que permite aos 
usuários manipular a essência dos dados, sem precisar conhecer a implementação. 

Considere as listagens 6.3 e 6.4. A primeira usa termos concretos para comunicar o nivel de 
combustível de um veiculo, enquanto a segunda faz o mesmo, só que usando . No caso concreto, 
você tem certeza de que ali estão apenas métodos acessores (escrita e leitura, ou getter e setter) 


de variáveis. No caso abstrato, não há como saber o tipo dos dados. 


Listagem 6-3 
Veículo concreto 


public interface Vehicle ( 
double getFuelTankCapacityInGallons(): 
double getGallonsOfCasoline(); 
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Listagem 6-4 
Veículo abstrato 


public interface Vehicle ( 


double getPercentFuelRemaining(); 
} 


Em ambos os casos acima, o segundo é preferível. Não queremos expor os detalhes de nossos 
dados. Queremos expressar nossos dados de forma abstrata. Isso não se consegue meramente 
através de interfaces e/ou métodos de escrita e leitura. É preciso pensar bastante na melhor 
maneira de representar os dados que um objeto contenha. A pior opção é adicionar levianamente 
métodos de escrita e leitura. 


Anti-simetria data/objeto 


Esses dois exemplos mostram a diferença entre objetos e estruturas de dados. Os objetos usam 
abstrações para esconder seus dados, e expõem as funções que operam em tais dados. As estruturas de 
dados expõem seus dados e não possuem funções significativas. Leia este parágrafo novamente. 

Note a natureza complementar das duas definições. Elas são praticamente opostas. Essa 
diferença pode parecer trivial, mas possui grandes implicações. 

Considere, por exemplo, a classe shape procedimental na Listagem 6.5. A classe Geometry 
opera em três classes shape que são simples estruturas de dados sem qualquer atividade. Todas 
as ações estão na classe Geometry. 


Listagem 6-5 
Classe shape procedimental 


public class Square ( 
public Point topLeft; 
public double side; 

) 


public class Rectangle ( 
public Point topLeft; 
public double height; 
public double width; 

} 

public class Circle { 
public Point cente! 
public double radius; 

) 


public class Geometry ( 
public final double FI - 3.141592653589793; 


public double area(Object shape! throws NoSuch: 
{ 
if (shape instanceof Square) { 
Square (Square) shape; 
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Listagem 6-5 (continuação) 
Classe shape procedimental 


else if (shape instanceof Rectangle) ( 
Rectangle r = (Rectangle)shape; 
return r.height * r.width; 
] 
else if (shape instanceof Circle) ( 
Circle c = (Circleishape; 
return PI * c.radius * c.radius; 
} 
throw new NoSuchShapeException(); 
} 


Programadores de orientação a objeto talvez torgam o nariz e reclamem que isso é 
procedimental —e estão certos. Mas nem sempre. Imagine о que aconteceria se adicionássemos 
uma função perimeter () à Geometry. As classes shape não seriam afetadas! Assim como 
quaisquer outras classes que dependessem delas! 

Por outro lado, se adicionarmos uma nova classe shape, teremos de alterar todas as funções em 
Geometry. Leia essa frase novamente. Note que as duas situações são completamente opostas. 

Agora, considere uma solução orientada a objeto na Listagem 6.6. O método área () é 
polifórmico. Não é necessária a classe Geometry. Portanto, se eu adicionar uma nova forma, 
nenhuma das funções existentes serão afetadas, mas se eu adicionar uma nova função, todas as 
classes shape deverão ser alteradas'. 


Listagem 6-6 

Classes shape polifórmicas 

public class Square implements Shape ( 
private Point topLet! 
private double side; 


public double агеа() { 
return side*side: 


c class Rectangle implements Shape { 
private Point topLeft; 
private double heigh 
private double width: 


public double area() ( 
return height * width; 
H 


1. Desenvolvedores orientados a objeto experiente conhecem outras maneiras de se contornar isso. O padrão Visitor, ou dual-dispatch. por exemplo. 


A lei de Demeter ^35 


Listagem 6-6 (continuação) 
Classes shape polifórmicas 


public class Circle ir 
private Point cente! 
private double radius; 
public final double PI - 3.141592653589 


lements Shape ( 


public double area() 
return PI * radius * radius; 


Novamente, vemos que a natureza complementar dessas duas definições: elas são praticamente 
opostas! Isso expõe a dicotomia fundamental entre objetos e estruturas de dados: 


O código procedimental (usado em estruturas de dados) facilita a adição de novas funções 
sem precisar alterar as estruturas de dados existentes. O código orientado a objeto (OO), por 
outro lado, facilita a adição de novas classes sem precisar alterar as funções existentes. 


O inverso também é verdade: 


O código procedimental dificulta a adição de novas estruturas de dados, pois todas as 
funções teriam de ser alteradas. O código OO dificulta a adição de novas funções, pois 
todas as classes teriam de ser alteradas. 


Portanto, o que é difícil para a OO é fácil para o procedimental, e o que é difícil para o 
procedimental é fácil para a OO! 

Em qualquer sistema complexo haverá vezes nas quais desejaremos adicionar novos tipos de x 
dados em vez de novas funções. Para esses casos, objetos e OO são mais apropriados. Por ouro 
lado, também haverá vezes nas quais desejaremos adicionar novas funções em vez de tipos de 
dados. Neste caso, estruturas de dados e código procedimental são mais adequados. 

Programadores experientes sabem que a ideia de que tudo é um objeto é um mito. As vezes, 
você realmente deseja estruturas de dados simples com procedimentos operando nelas. 


A lei de Demeter 


Há uma nova heurística muito conhecida chamada Lei de Demeter*: um módulo não deve enxergar 
o interior dos objetos que ele manipula. Como vimos na seção anterior, os objetos escondem seus 
dados e expõem as operações. Isso significa que um objeto não deve expor sua estrutura interna 
por meio dos métodos acessores, pois isso seria expor, e não ocultar, sua estrutura interna. 

Mais precisamente, a Lei de Demeter diz que um método f de uma classe C só deve chamar 
os métodos de: 


“Cc 

+ Um objeto criado por f 

* Um objeto passado como parámetro para f 

* Um objeto dentro de uma instáncia da variável C 


2 реп wikipcdis.org/wiki/Law. of Demeter 
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O método não deve chamar os métodos em objetos retornados por qualquer outra das funções 
permitidas. Em outras palavras, fale apenas com conhecidos, não com estranhos. 

O código seguinte parece violar a Lei de Demeter (dentre outras coisas). pois ele chama a 
função getScratchDir() no valor retornado de getOptions() e, então, chama getAbsolutePath() no 
valor retornado de getScratchDir(). 


final String outputDir = ctxt.getOptions().getScratchDir(). 
getAbsolutePath(); 


Carrinhos de trem 


Esse tipo de código costuma ser chamador de carrinho de trem, pois parece com um monte 
de carrinhos de trem acoplados. Cadeias de chamadas como essa geralmente são consideradas 
descuidadas e devem ser evitadas [G36]. Na maioria das vezes é melhor dividi-las assim: 


Options opts = ctxt.getOptions(); 
File scratchDir = opts.getScratchDir(); 
final String outputDir = scratchDir.getAbsolutePath(); 


Esses dois pedaços de código violam a 
Lei de Demeter? Certamente módulo que os 
contém sabe que o objeto ctxt possui opções 
(options), que contêm um diretório de rascunho 
(scratchDir), que tem um caminho absoluto 
(AbsolutePath). É muito conhecimento para 
uma função saber. A função de chamada sabe 
como navegar por muitos objetos diferentes. 

Se isso é uma violação da Lei de Demeter depende se ctxt, Options e ScracthDir são 
ou não objetos ou estruturas de dados. Se forem objetos, então sua estrutura interna deveria estar 
oculta ao invés de exposta, portanto o conhecimento de seu interior é uma violação clara da lei. 
Por outro lado, se forem apenas estruturas de dados sem atividades. então eles naturalmente 
expõem suas estruturas internas. portanto aqui não se aplica a lei. 

O uso de funções de acesso confunde essas questões. Se o código tiver sido escrito como 
abaixo, então provavelmente não estaríamos perguntando sobre cumprimento ou não da lei. 


final String outputDir = ctxt.options.scratchDir.absolutePath; 


Essa questão seria bem menos confusa se as estruturas de dados simplesmente tivessem 
variáveis públicas e nenhuma função, enquanto os objetos tivessem apenas variáveis privadas e 
funções públicas. Entretanto, há frameworks e padrões (e.g., "beans ") que exigem que mesmo 
estruturas de dados simples tenham métodos acessores e de alteração. 


iddedondücsDS CU de Aide: 
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Híbridos 


De vez em quando, essa confusão leva a estruturas híbridas ruins que são metade objeto e metade 
estrutura de dados. Elas possuem funções que fazem algo significativo, e também variáveis ou 
métodos de acesso e de alteração públicos que, para todos os efeitos, tornam públicas as variáveis 
privadas, incitando outras funções externas a usarem tais variáveis da forma como um programa 
procedimental usaria uma estrutura de dados*. 

Esses híbridos dificultam tanto a adição de novas funções como de novas estruturas de dados. 
Eles são a pior coisa em ambas as condições. Evite criá-los. Eles indicam um modelo confuso cujos 
autores não tinham certeza — ou pior, não sabiam — se precisavam se proteger de funções ou tipos. 


Estruturas ocultas 


E se ctxt, options e scratchDir forem objetos com ações reais? Então, como os objetos 
devem ocultar suas estruturas internas, não deveríamos ser capazes de navegar por eles. Então, 
como conseguiríamos o caminho absoluto de scratchDir ( “diretório de rascunho”)? 


ctxt .getAbsolutePathofScratchDirectoryOption( 1 
ou 
ctx.getScratchDirectoryOption().getAbsolutePath() 


A primeira opção poderia levar a uma abundância de métodos no objeto ctxt. A segunda 

presume que getScratchDirectoryOption() retorna uma estrutura de dados. e não 

um objeto. Nenhuma das opções parece boa. 

Se ctxt for um objeto, devemos dizê-lo para fazer algo; não devemos perguntá-lo sobre sua 
estrutura interna. Por que queremos o caminho absoluto de scratchDir? O que faremos com ele? 
Considere o código, muitas linhas abaixo, do mesmo módulo: 


String outFile = outputDir + */" + className.replace('.', \/') + 
“class”; 

FileOutputStream fout = new FileOutputStream(outFile); 
BufferedOutputStream bos = new BufferedOutputStream(fout): 


A mistura adicionada de diferentes níveis de detalhes [G34][G6] é um pouco confusa. Pontos, 
barras, extensão de arquivos e objetos Fi Le não devem ser misturados entre si e nem com o código 
que os circunda. Ignorando isso, entretanto, vimos que a intenção de obter o caminho absoluto do 
diretório de rascunho era para criar um arquivo de rascunho de um determinado nome. 

Então, e se disséssemos ao objeto ctxt para fazer isso? 


BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName); 


That seems like a reasonable thing for an object to do! Isso permite ao ctxt esconder sua estrutura 
interna e evitar que a função atual viole a Lei de Demeter ao navegar por objetos os quais ela 
não deveria enxergar. 


4. Às vezes chama-se de Feature Envy em [Refatora, 
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Objetos de transferência de dados 


A forma perfeita de uma estrutura de dados é uma classe com variáveis públicas e nenhuma função. 

Às vezes, chama-se isso de objeto de transferência de dados, ou DTO (sigla em inglês). Os 
DTOs são estruturas muitos úteis, especialmente para se comunicar com bancos de dados ou 
analisar sintaticamente de mensagens provenientes de sockets e assim por diante. Eles costumam 
se tornar os primeiros numa série de estágios de tradução que convertem dados brutos num banco 
de dados em objetos no código do aplicativo. 

De alguma forma mais comum é o formulário “bean” exibido na Listagem 6.7. Os beans têm 
variáveis privadas manipuladas por métodos de escrita e leitura. O aparente encapsulamento dos 
beans parece fazer alguns puristas da OO sentirem-se melhores, mas geralmente não oferece 
vantagem alguma. 


Listagem 6-7 
address. java 


public class Address ( 
private String 
private Stru 
private String 
private String 
private String 


public Address(String street, String streetExtra, 
String city, String state, String zip) ( 
this.street - street; 
this.streetExtra - streetExtra; 
this.city = city; 


) 


public String getStreet() ( 
return street; 
) 


public String getStreecExtra(| 
return streetExtra; 


) 


public String getCity() ( 
return city; 
1 


public String getState() { 
return state; 


L 


public String gerzip() ( 
return 


) 


Bibliografia 101 


O Active Record 


Os Active Records são formas especiais de DTOs. Eles são estruturas de dados com variáveis 
públicas (ou acessadas por Beans); mas eles tipicamente possuem métodos de navegação, como 
save (salvar) e find (buscar). Esses Active Records são traduções diretas das tabelas de bancos 
de dados ou de outras fontes de dados. 

Infelizmente, costumamos encontrar desenvolvedores tentando tratar essas estruturas de dados 
como se fossem objetos, colocando métodos de regras de negócios neles. Isso é complicado, pois 
cria um híbrido entre uma estrutura de dados e um objeto. 

A solução. é claro, é tratar o Record Active como uma estrutura de dados e criar objetos 
separados que contenham as regras de negócio e que ocultem seus dados internos (que 
provavelmente são apenas instâncias do Active Record). 


Conclusão 


Os objetos expõem as ações e ocultam os dados. Isso facilita a adição de novos tipos de objetos 
sem precisar modificar as ações existentes e dificulta a inclusão de novas atividades em objetos 
existentes. As estruturas de dados expõem os dados e não possuem ações significativas. Isso 
facilita a adição de novas ações às estruturas de dados existentes e dificulta a inclusão de novas 
estruturas de dados em funções existentes. 

Em um dado sistema, às vezes, desejaremos flexibilidade para adicionar novos tipos de 
dados, e, portanto, optaremos por objetos. Em outras ocasiões, desejaremos querer flexibilidade 
para adicionar novas ações, e, portanto, optaremos tipos de dados e procedimentos. 

Bons desenvolvedores de software entendem essas questões sem preconceito e selecionam a, 
abordagem que melhor se aplica no momento. 


Bibliografia 


[Refatoração] Refatoração - Aperfeiçoando o Projeto de Código Existente, Martin Fowler et 
al., Addison-Wesley, 1999. 
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Tratamento de Erro 


por Michael Feathers 


Pode parecer estranho ter uma seção sobre tratamento de erro num livro sobre código limpo, 
mas essa tarefa é uma das quais todos temos de fazer quando programamos. A entrada pode 
estar errada e os dispositivos podem falhar. Em suma, as coisas podem dar errado, e quando isso 
ocorre, nós. como programadores, somos responsáveis por certificar que nosso código faça o que 
seja preciso fazer. 

A conexão com um código limpo, entretanto, deve ser clara. O tratamento de erro domina 
completamente muitos códigos-fonte. Quando digo “domina”, não quero dizer que eles só fazem 
tratamento de erro, mas que é quase impossível ver o que o código faz devido a tantos tratamentos 
de erros espalhados. Esse recurso é importante, mas se obscurecer a lógica, está errado. 

Neste capítulo ressaltarei uma série de técnicas e considerações que você pode usar para criar 
um código que seja limpo e robusto, que trate de erros com elegância e estilo. 
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Use exceções em vez de retornar códigos 


Num passado longínquo havia muitas linguagens que não suportavam exceções. Nelas, as 
técnicas para tratar e informar erros era limitada. Ou você criava uma flag de erro ou retornava 
um código de erro que o chamador pudesse verificar. O código na Listagem 7.1 ilustra essas 
abordagens. 


Listagem 7-1 
DeviceController.java 


public class DeviceController ( 


public void sendShutbown() ( 
DeviceHandle handle = getHandleiDEVl!; 
#1 Check the state of the device 
if (handle !- DeviceHandle.INVALID) { 
/| Save the device status to che record field 
retrieveDeviceRecord (handle) ; 
// 1f not suspended, shut down 
if (record.getStatus() !- DEVICE SUSPENDED) { 
pauseDevice ihandle) ; 
clearDeviceWorkQueue (handle) ; 
closeDevice (handle) ; 
else { 
logger.log(*Device suspended. Unable to shut down"); 


se ( 


) el 
logger.log(*Invalid handle for: * + DEVI.toString()); 


O problema era que essas técnicas entupiam o chamador, que devia verificar erros 
imediatamente após a chamada. Infelizmente, facilmente se esqueciam de fazer isso. Por esse 
motivo, é melhor lançar uma exceção quando um erro for encontrado. O código de chamada fica 
mais limpo e sua lógica nào fica ofuscada pelo tratamento de erro. 

A Listagem 7.2 mostra o código depois de termos optado por lançar exceções em métodos 
que podem detectar erros. 


Listagem 7-2 
DeviceController.java (com exceções) 


public class DeviceController ( 


public void sendShutDown() ( 
try ( 
tryToShutDown() ; 
) catch (DeviceShutDownError e) ( 
logger.logíe); 
H 
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Listagem 7-2 (continuação): 
DeviceController.java (com exceções) 


private void tryToShutDown() throws DeviceShutDownError { 
DeviceHandle handl getHandle(DEVl 
DeviceRecord record = retrieveDeviceRecord (handle) ; 


pauseDevice (handle) ; 
clearDeviceWorkQueue (handle) ; 
closeDevice (handle) ; 


private DeviceHandle getHandie (DeviceID id) { 


throw new DeviceShutDownError( "Invalid handle for: * + id.toString()); 


Observe como fica muito mais claro. Isso não é apenas uma questão estética. O código fica 
melhor porque duas preocupações que estavam intrincadas, o algoritmo para o desligamento 
do dispositivo e o tratamento de erro, agora estão separadas. Você pode pegar cada uma delas e 
estudá-las independentemente. 
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Uma das coisas mais interessantes sobre exceções é que elas definem um escopo dentro de 
seu programa. Ao executar o código na parte try da estrutura try...catch.. finally, você declara que 
aquela execução pode ser cancelada a qualquer momento e, então, continuar no catch. 

De certa forma, os blocos try são como transações. Seu catch tem de deixar seu programa 
num estado consistente, nào importa o que aconteça no try. Por essa razão, uma boa prática é 
começar com uma estrutura try...catch...finally quando for escrever um código que talvez lance 
exceções. Isso lhe ajuda a definir o que o usuário do código deve esperar, independente do que 
ocorra de errado no código que é executado no try. 

Vejamos um exemplo. Precisamos criar um código que acesse um arquivo e consulte alguns 
objetos em série. 

Começamos com um teste de unidade que mostra como capturar uma exceção se o 
arquivo nào existir: 


GTest(expected = StorageException.class) 

public void retrieveSectionShouldThrowOnInvalidFileName() ( 
sectionStore.retrieveSection(*invalid - file"); 

> 


O teste nos leva a cria esse stub: 
public List<RecordedGrip> retrieveSection(String sectionName) ( 


// retorno ficticio ate que tenhamos uma implementacao real 
return new ArrayList<RecordedGrip>(); 
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Nosso teste falha porque cle não lança uma exceção. Em seguida, mudamos nossa implementação 
de modo a tentar acessar um arquivo inválido. Essa operação lança uma exceção: 


public List<RecordedGrip> retrieveSection(String sectionName) ( 
try { 
FileInputStream stream - new FileInputStream(sectionName) 
) catch (Exception e) ( 
throw new StorageException(“retrieval error", e); 
} 
return new ArrayList<RecordedGrip>(); 
} 


Nosso teste funciona agora porque capturamos a exceção. Neste momento, podemos refatorar. 
Podemos reduzir o tipo de execução que capturamos para combinar com aquele que realmente 
é lançado pelo construtor Fi leInputStream: FileNotFoundException: 


public List<RecordedGrip> retrieveSection(String sectionName) ( 


try ( 
FileInputStream stream = new FileInputStream(sectionName); 
stream.close(); 

} catch (FileNotFoundException e) { 
throw new StorageException(*retrieval error", e); 


) 


return new ArrayList<RecordedGrip>(); 
) 


Agora que definimos o escopo com uma estrutura try...catch, podemos usar о TDD para 
construir o resto da lógica que precisamos, que será adicionada па criação do FilelnputStream do 
close e poderá fingir que nada de errado aconteceu. 

Experimente criar testes que forçam exceções e, então, adicione a ação ao seu tratador para 
cumprir seus testes. Isso fará com que você crie primeiro o escopo de transação do bloco try e lhe 
ajudará a manter essa natureza de transação daquele escopo. 


Use exceções não verificadas 


A discussão acabou. Por anos, programadores Java têm discutido sobre as vantagens e 
desvantagens de exceções verificadas. Quando a verificação exceções surgiu com a primeira 
versão do Java, parecia uma ótima ideia, A assinatura de todo método listaria todas as exceções 
que ele passaria ao seu chamador. Ademais, essas exceções eram parte do tipo do método. Seu 
código literalmente não seria compilado se a assinatura não fosse a mesma da que seu código 
podia fazer. 

Naquela época, pensamos que exceções verificadas fosse uma ideia ótima; e era, elas tinham 
algumas vantagens. Entretanto, ficou claro agora que elas não são necessárias para a produção 
de um software robusto. O C£ não verifica exceções, e, apesar das tentativas, nem o C++. Nem 
mesmo Python ou Ruby. Ainda assim é possível criar um software robusto em todas essas 
linguagens, porque, nesse caso, temos de decidir se realmente as exceções verificadas valem o 
preço que se paga. 

Que preço? O de verificar exceções é a violação do Princípio de Aberto-Fechado'. 

Se você lançar uma exceção a ser verificada a partir de um método em seu código e o 


1. [Marin]. 
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catch estiver três níveis acima, será preciso declará-la na assinatura de cada método entre 
você e o catch. Isso significa que uma modificação em um nível mais baixo do software pode 
forçar a alteração de assinaturas em muitos níveis mais altos. Os módulos alterados podem ser 
reconstruídos e redistribuídos, mesmo que nada inerente a eles tenha sido mudado. 

Considere a hierarquia de chamadas de um sistema grande. As funções no topo chamam 
as abaixo delas, que chamam outras abaixo delas e ad infinitum. Agora digamos que uma das 
funções dos níveis mais baixos seja modificada de uma forma que ela deva lançar uma exceção. 
Se essa exceção for verificada, então a assinatura da função deverá adicionar uma instrução 
throws. Mas isso significa que cada função que chamar nossa função modificada também deverá 
ser alterada para capturar a nova exceção ou anexar a instrução throws apropriada a sua assinatura. 
Ad infinitum. O resultado aninhado é uma cascata de alterações que vão desde os níveis mais 
baixo do software até o mais alto! Quebra-se o encapsulamento, pois todas as funções no caminho 
de um lançamento (throw) devem enxergar os detalhes daquela exceção de nível mais baixo. 
Segundo o propósito de exceções de que elas lhe permitem tratar erros distantes, é uma pena que 
as exceções verificadas quebrem dessa forma o encapsulamento. 

As exceções verificadas podem às vezes ser úteis se você estiver criando uma biblioteca crítica: 
é preciso capturá-las. Mas no desenvolvimento geral de aplicativo, os custos da dependência 
superam as vantagens. 


Forneça exceções com contexto 


Cada exceção lançada deve fornecer contexto o suficiente para determinar a fonte e a localização 
de um erro. Em Java, você pode pegar um stack trace de qualquer exceção; entretanto, ele não 
consegue lhe dizer o objetivo da operação que falhou. 

Crie mensagens de erro informativas e as passe juntamente com as exceções. Mencione a 
operação que falhou e o tipo da falha. Se estiver registrando as ações de seu aplicativo, passe 
informações suficientes para registrar o erro de seu catch. 


Defina as classes de exceções segundo as necessidades 
do chamador 


Há muitas formas de classificar erros. Pode ser pela origem: eles vieram desse componente ou 
daquele? Pelo tipo: são falhas de dispositivos, de redes ou erros de programação? Entretanto, 
quando definimos as classes de exceção num aplicativo, nossa maior preocupação deveria ser 
como elas são capturadas. 

Vejamos um exemplo de uma classificação ruim de exceção. Aqui, há uma estrutura try... 
catch..finally para uma chamada a uma biblioteca de outro fabricante. Ela cobre todas as 
exceções que a chamada talvez lance: 


ACMEPort port = new ACMEPort(12); 


try { 
port.open(); 
) catch (DeviceResponseException e) { 
reportPortError(e); 
logger.log("Device response exception”, e); 
) catch (ATM1212UnlockedException e) ( 
reportPortError(e); 
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logger.log("Unlock exception", е); 
) catch (GMXError e) í 

reportPortError (e); 

logger.log(*Device response exception"); 
) finally ( 


) 


A estrutura possui muita duplicação, e não deveriamos estar surpresos. Na maioria dos casos 
de tratamento de exceções, o que fazemos é relativamente padrão, independente da situação no 
momento. Temos de registrar um erro e nos certificar que podemos prosseguir. 

Neste caso. como sabemos que a tarefa que estamos fazendo é basicamente a mesma independente 
da exceção, podemos simplificar nosso código consideravelmente. Para isso, pegamos à API que 
estamos chamando e garantimos que ela retorne um tipo comum de exceção. 


LocalPort port = new LocalPort(12); 

try ( 
port.open(); 

) catch (PortDeviceFailure e) ( 
reportError(e); 
logger.log(e.getMessage(), e); 

} finally { 


} 


Nossa classe LocalPort é um simples wrapper (“empacotador”) que captura e traduz as 
exceções lançadas pela classe ACMEPort: 


public class LocalPort ( 
private ACMEPort innerPort; 


public LocalPort(int portNumber) ( 
innerPort = new ACMEPort(portNumber); 
} 


public void open() { 
try ( 
innerPort.open(); 
) catch (DeviceResponseException e) ( 
throw new PortDeviceFailure(e); 
} catch (ATM1212UnlockedException e) ( 
throw new PortDeviceFailure(e); 
) catch (GMXError e) ( 
throw new PortDeviceFailure(e); 
+ 


› 


Wrappers como о que definimos para a ACMEPort podem ser muito úteis. Na verdade, 
empacotar APIs de terceiros é a melhor prática que existe. Ao fazer isso, você minimiza as 
dependências nelas: você pode escolher migrar para uma biblioteca diferente no futuro sem 
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muitos problemas. Empacotar também facilita a simulação de chamadas de terceiros quando for 
testar seu próprio código. 

Uma última vantagem de empacotar (wrapping) é que você não fica preso às escolhas do 
modelo de API de um fornecedor em particular. Você pode definir a API que preferir. No exemplo 
anterior. definimos um único tipo de exceção para a falha do dispositivo port e descobrimos que 
poderíamos escrever um código muito mais limpo. 

Geralmente, uma única classe de exceção está bom para uma parte específica do código. 
As informações enviadas com a exceção podem distinguir os erros. Use classes diferentes 
apenas se houver casos em que você queira capturar uma exceção e permitir que a outra 
passe normalmente. 
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acabará com uma boa quantidade de divisão entre 
sua lógica do negócio e seu tratamento de erro. ^ 
A maioria de seu código começará a parecer um 
algoritmo limpo e sem apetrechos. Entretanto, esse 
processo eleva ao máximo a detecção de erro em 
seu programa. Você empacota suas APIs de modo 
que você possa lançar suas próprias exceções e 
definir um controlador acima de seu código para 
que você possa lidar com qualquer computação 
cancelada. Na maioria das vezes, essa é uma abordagem ótima, mas há situações nas quais você. 
talvez não queira cancelar. 

Vejamos um exemplo. Abaixo está um código confuso que soma as despesas em um aplicativo 
de finanças: 


try ( 
MealExpenses expenses - expenseReportDAO.getMeals(employee. 
getID(); 
m total «- expenses.getTotal(); 
) catch(MealExpensesNotFound e) { 
m total += getMealPerDiem(); 
} 


Neste negócio, se as refeições (meals) forem um custo, elas se tornam parte do total. Caso 
contrário, o funcionário (employee) recebe uma quantia para ajuda de custos (PerDiem) pela 
refeição daquele dia. A exceção confunde a lógica. 

Não seria melhor se não tivéssemos de lidar com o caso especial? Dessa forma, nosso código 
seria muito mais simples. Ele ficaria assim: 


MealExpenses expenses = expenseReportDAO.getMeals(employee.getID()); 
m total += expenses.getTotal(); 


Podemostornarocódigomaissimples? Parecequesim. Podemosalterara ExpenseReportDAO 
de modo que ela sempre retorne um objeto MealExpense. Se não houver gastos com refeições, 
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ela retorna um objeto MealExpense que retorna a ajuda de custos como seu total: 
public class PerDiemMealExpenses implements MealExpenses ( 
public int getTotal() { 
// retorna a ajuda de custos padrao 
I 
) 


Isso se chama o Padrão Special Case (‘padrão do caso especial’), de Fowler. Você cria uma 
classe ou configure um objeto de modo que ele trate de um caso especial para você. Ao fazer 
isso, o código do cliente não precisa lidar com o comportamento diferente. Este fica encapsulado 
num objeto de caso especial. 


Não retorne null 


Acho que qualquer discussão sobre tratamento de erro deveria incluir as coisas que fazemos que 
levam a erros. A primeira da lista seria retornar null. Já perdi a conta dos aplicativos que já vi que 
em quase toda linha verificava por null. Abaixo está um exemplo: 


public void registerItem(Item item) ( 
if (item != null) ( 
ItemRegistry registry = peristentStore.getItemRegistry(); 
if (registry != null) ( 
Item existing = registry.getItem(item.getID()); 
if (existing.getBillingPeriod().hasRetailOwner()) ( 
existing.register(item): 


) 


} 


Se você trabalhar num código-fonte como esse, ele pode não parecer tão ruim assim para 
você, mas ele é! Quando retornamos nu11, basicamente estamos criando mais trabalho para nós 
mesmos e jogando problemas em cima de nossos chamadores. Só basta esquecer uma verificação 
null para que o aplicativo fique fora de controle. 

Percebeu que não havia uma verificação de null na segunda linha do if aninhado? O que 
teria acontecido em tempo de execução se persistentstore fosse null? Teríamos uma 
NullPointerExcept ion em tempo de execução, e ou alguém está capturando-a no nivel mais 
alto ou não. Em ambos os casos isso é péssimo. O que você faria exatamente em resposta a um 
lançamento de Null PointerException das profundezas de seu aplicativo? 

É fácil dizer que o problema com o código acima é a falta de uma verificação de null, 
mas, na verdade, o problema é que ele tem muitos. Se você ficar tentado a retornar nu11 de um 
método, em vez disso, considere lançar uma exceção ou retornar um objeto SPECIAL CASE. 
Se estiver chamando um método que retorne nu11 a partir de uma АРІ de terceiros, considere 
empacotá-lo com um método que lance uma exceção ou retorne um objeto de caso especial. 

Em muitos casos. objetos de casos especiais são uma solução fácil. Imagine que seu código 
fosse assim: 


List«Employee» employees = getEmployees(); 
if (employees != null) ( 
for (Employee e : employees) { 
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totalPay += e.getPay(); 


} 


Neste momento, getEmployees pode retornar null, mas ele precisa? Se alterássemos getEmployee 
de modo que ele retornasse uma lista vazia, poderíamos limpar o código: 


List<Employee> employees = getEmployees(); 
for (Employee e : employees) ( 

totalPay += e.getPay(); 
р) 


Felizmente, Java possui o Collections.emptyList(), e ele retorna uma lista predefinida e imutável 
que podemos usar para esse propósito: 


public List<Employee> getEmployees() ( 
if( .. there are no employees .. ) 

return Collections .emptyList(); 
} 


Se programar dessa forma, você minimizará a chance de NullPointerExceptions e seu 
código será mais limpo. 


Não passe null 


Retornar null dos métodos é ruim, mas passar nu11 para eles é pior. A menos que esteja 
trabalhando com uma API que espere receber nul1, você deve evitar passá-lo em seu código 
sempre que possível. S 

Vejamos um exemplo do porquê. Abaixo está um método simples que calcula a distância 
entre dois pontos: 


public class MetricsCalculator 
t 


public double xProjection(Point pl, Point p2) ( 
return (p2.x - pl.x) * 1.5; 
J 
) 


O que acontece quando alguém passa nu11 como parámetro? 


calculator.xProjection(null, new Point(12, 13)); 


Receberemos uma NullPointerException, é claro. 
Podemos consertar isso? Poderíamos criar um novo tipo de exceção e lancá-lo: 


public class MetricsCalculator 

{ 
public double xProjection(Point pl, Point p2) { 
if (pl == null || p2 null) ( 
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throw InvalidArgumentException( 
"Invalid argument for 
MetricsCalculator.xProjection*); 
) 
return (p2.x - pl.x) * 1.5; 


) 


Ficou melhor? Pode ser um pouco melhor do que uma exceção de ponteiro nu11, mas lembre-se 
de que temos de definir um tratador para Inval idargumentException. O que ele deve fazer? 
На algum procedimento bom? 

Há uma alternativa. Poderiamos usar uma série de confirmações: 


public class MetricsCalculator 
t 
public double xProjection(Point pl, Point p2) ( 
assert pl !- null : "pl não pode ser nulo”; 
assert p2 !- null : “p2 não pode ser nulo”; 
return (p2.x - pl.x) * 1.5; 


) 


É uma boa informação, mas não resolve o problema. Se alguém passar nu11, ainda teremos um 
erro em tempo de execução. 

Na maioria das linguagens de programação não há uma boa forma de lidar com um valor nulo 
passado acidentalmente para um chamador. Como aqui este é o caso, a abordagem lógica seria 
proibir, por padrão, a passagem de nu11. Ao fazer isso, você pode programar com o conhecimento 
de que um null numa lista de parâmetros é sinal de problema, e acabar com mais alguns erros 
por descuido. 


Conclusão 


Um código limpo é legível, mas também precisa ser robusto. Esses objetivos não são conflitantes. 
Podemos criar programas limpos e robustos se enxergarmos o tratamento de erro como uma 
preocupação à parte, algo que seja visível independentemente de nossa lógica principal. Na 
medida em que somos capazes de fazer isso, podemos pensar nisso de forma independente e dar 
um grande passo na capacidade de manutenção de nosso código. 
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Limites 


por James Grenning 


Raramente controlamos todos os softwares em nossos sistemas. De vez em quando compramos 
pacotes de outros fabricantes ou usamos códigos livres, ou dependemos de equipes em nossa própria 
empresa para construir componentes ou subsistemas para nós. De algum modo, devemos integrar, 
de forma limpa, esse código externo ao nosso. Neste capítulo veremos as práticas e técnicas para 
manter limpos os limites de nosso software. 
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O uso de códigos de terceiros 


Há uma tensão natural entre o fornecedor de uma interface e seu usuário. Os fornecedores de 
pacotes e frameworks de outros fabricantes visam a uma maior aplicabilidade de modo que 
possam trabalhar com diversos ambientes е atender a um público maior. Já os usuários desejam 
uma interface voltada para suas próprias necessidades. Essa tensão pode causar problemas nos 
limites de nossos sistemas. 

Tomemos о java.util.Map como exemplo. Como pode ver na Figura 8.1, os Maps tem 
uma interface bastante ampla com diversas capacidades. Certamente esse poder e flexibilidade 
são úteis, mas também pode ser uma desvantagem. Por exemplo, nosso aplicativo pode construir 
um Map e passá-lo adiante. Nosso objetivo talvez seja que nenhum dos recipientes de nosso 
Map não exclua nada do Map. Mas logo no início da lista está o método clear (). Qualquer 
usuário do Map tem o poder de apagá-lo. Ou talvez, segundo a convenção que adotamos, o Map 
pode armazenar apenas certos tipos de objetos, mas não é certo que ele restrinja os tipos que 
são adicionados a ele. Qualquer usuário determinado pode adicionar itens de qualquer tipo a 
qualquer Map. 

Se nosso aplicativo precisa de um Map de Sensors, você pode se deparar com um Sensors assim: 


clear() void - Map 

containsKey(Object key) boolean - Map 
containsValue(Object value) boolean - Map 
entrySet() Set - Map 

equals(Object o) boolean - Map 

get(Object key) Object - Map 

getClass() Class«? extends Object» - Object 
hashCode() int - Map 

isEmpty() boolean - Map 

keySet() Set - Map 

notify() void - Object 

notifyAll() void - Object 

put(Object key, Object value) Object - Map 
putAll(Map t) void - Map 

remove(Object key) Object - Map 

size() int - Map 

toString() String - Object 

values() Collection - Map 

wait() void - Object 

wait(long timeout) void - Object 

wait(long timeout, int nanos) void - Object 


Figura 8.1: Métodos do Map 


Se nosso aplicativo precisar de um Map de sensors, vocé talvez encontre sensors assim: 
Map sensors - new HashMap(); 
E, quando alguma outra parte do código precisa acessar o Sensor, você vê isso: 


Sensor s = (Sensor)sensors.get(sensorld ); 
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Não vemos isso apenas uma vez, mas várias ao longo do código. O cliente deste código fica com 
a responsabilidade de obter um Object do Map e atribuí-lo o tipo certo. Apesar de funcionar, não 
é um código limpo. Ademais, esse código não explica muito bem o que ele faz. Pode-se melhorar 
consideravelmente sua legibilidade com o uso de tipos genéricos, como mostra abaixo: 


Map<Sensor> sensors = new HashMap<Sensor>(); 


Sensor s = sensors.get(sensorld ); 


Entretanto, isso nào resolve o problema de que Map<sensor> oferece mais capacidade do que 
precisamos ou queremos. 

Passar adiante pelo sistema uma instância de Map<Sensor> significa que haverá vários 
lugares para mexer se a interface para o Map mudar. Você talvez pense que uma mudança seja 
pouco provável. mas lembre-se de que houve uma quando o suporte a genéricos foi adicionado 
no Java 5. De fato, já vimos sistemas que impedem o uso de genéricos devido à magnitude das 
alterações necessárias para manter о uso abrangente dos Maps. 

Abaixo está uma forma limpa de usar o Map. Nenhum usuário do Sensors se importaria se 
um pouco de genéricos for usado ou não. Essa escolha se tornou (e sempre deve ser) um detalhe 
da implementação. 


public class Sensors { 
private Map sensors = new HashMap(); 


public Sensor getById(String id) ( 
return (Sensor) sensors.get(id): 


} 
//codigo 
} 


A interface no limite (Map) está oculta. É possível alterá-la causando muito pouco impacto no 
resto do aplicativo. O uso de tipos genéricos não é mais uma questão tão problemática assim, 
pois o gerenciamento de declarações e de tipos é feito dentro da classe Sensors. 

Essa interface também foi personalizada para satisfazer as necessidades do aplicativo. Seu 
resultado é um código mais fácil de se entender e mais dificil de ser utilizado incorretamente. A classe 
Sensors pode forçar regras de modelo e de negócios. 

Não estamos sugerindo que cada uso do Map seja encapsulado dessa forma. Mas lhe aconselhando 
para não passar os Maps (ou qualquer outra interface num limite) por todo o sistema. Se usar uma 
interface, como a Map, no limite, a mantenha numa classe ou próxima a uma família de classes em 
que ela possa ser usada. Evite retorná-la ou aceitá-la como parâmetro em APIs públicas. 


Explorando e aprendendo sobre limites 


Códigos de terceiros nos ajudam a obter mais funcionalidade em menos tempo. Por onde começar 
quando desejamos utilizar pacotes de terceiros? Não é tarefa nossa testá-los, mas pode ser melhor 
para nós criar testes para os códigos externos que formos usar. 

Suponha que não esteja claro como usar uma biblioteca de terceiros. Podemos gastar um dia 
ou dois (até mais) lendo a documentação e decidindo como vamos usá-la. Então, escreveríamos 
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nosso código para usar o código externo e vemos se ele é ou nào o que achávamos. Nào 
ficaríamos surpresos de acabar em longas sessões de depuração tentando descobrir se os bugs 
que encontramos são do nosso código ou no deles. 

Entender códigos de terceiros é difícil. Integrá-lo ao seu também é. Fazer ambos ao mesmo 
tempo dobra a dificuldade. E se adotássemos uma outra abordagem? Em vez de experimentar e 
tentar o novo código. poderiamos criar testes para explorar nosso conhecimento sobre ele. Jim 
Newkirk chama isso de testes de aprendizagem'. 

Nesses testes, chamamos a API do código externo como o faríamos ao usá-la em nosso 
aplicativo. 

Basicamente estaríamos controlando os experimentos que verificam nosso conhecimento 
daquela API. 

O teste se focaliza no que desejamos saber sobre a API, 


Aprendendo sobre 10g4j 


Digamos que queremos usar o pacote 1094j do Apache em vez de nosso próprio gravador de 
registro interno. 

Baixaríamos o pacote e então abriríamos a página de documentação inicial. Sem ler muito, 
criamos nosso primeiro caso de teste, esperando que seja impresso “oi” no console. 


@Test 
public void testLogCreate() ( 
Logger logger = Logger.getLogger("MyLogger"); 
logger.info(*oi”); 


H 


Quando o executamos, o registrador (logger) produz um erro o qual nos diz que precisamos de algo 
chamado Appender. Após ler um pouco mais, descobrimos que existe um Consol eAppender. Então, 
criamos um ConsoleAppender e vemos se desvendamos os segredos de registro no console. 


Test 

public void testLogAddAppender() ( 
Logger logger = Logger.getLogger("MyLogger"); 
ConsoleAppender appender = new ConsoleAppender(); 
logger.addAppender (appender); 
logger.info(*oi"); 


Desta vez, descobrimos que o Appender não possui fluxo de saída. Estranho... Parecia lógico ter 
um. Depois de buscar ajuda no Google, tentamos o seguinte: 


@Test 

public void testLogAddAppender() { 
Logger logger = Logger.getLogger("MyLogger*); 
logger.removeAllAppenders(); 
logger.addAppender(new ConsoleAppender( 
new PatternLayout("$p $t %т%п”), 
ConsoleAppender.SYSTEM, OUT)); 
logger.info(*oi"); 


Ai Bie TOR m bee teh 
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Funcionou. Uma mensagem de registro com “oi” apareceu no console! Parece estranho ter de 
dizer ao ConsoleAppender o que ele precisa escrever no console. Mais interessante ainda é 
quando removemos o parámetro ConsoleAppender .SystemOut e ainda é exibido “oi”. Mas 
quando retiramos о PatternLayout, mais uma vez há mensagem de falta de um fluxo de saída. 
Esse comportamento é muito estranho. 

Lendo a documentação com um pouco mais de atenção, vimos que o construtor 
Consoleappender padrão vem “desconfigurado”, o que não parece muito óbvio ou prático. 
Parece um bug, ou pelo menos uma inconsistência, no 10943. Recorrendo novamente ao Google, 
lendo e testando, acabamos chegando à Listagem 8.1. Descobrimos bastante coisa sobre como 
funciona о 10943, e colocamos esse conhecimento numa série de testes simples de unidade. 


Listagem 8-1 
LogTest.java 


public class LogTest | 
rivate Logger logger; 


H êBofore 

i public void initialize() { 
ger = Logger .getLogger ("logger"); 
logger.removeAllAppenders() ; 

Logger .getRoot Logger () .removeAllAppenders () ; 


) 

GTest 

public void basicLogger() ( 
BasicConfigurator.configure(!; 
logger. info (“basicLogger* 


) 


Test 
public void addAppenderWithStream() ( 
logger.addAppender (new ConsoleAppender ( 
new PatternLayout("$p $t min"), 
ConsoleAppender.SYSTEM OUT!) ; 
logger. info (*addappenderWithstream*) ; 
) 


atest 
public void addAppenderWithoutStream() £ 
logger .addAppender (new ConsoleAppender í 
new PatternLayout ("tp $t tm&n")}); 
logger .info(*addAppenderWithoutStream") ; 


Agora sabemos como obter um console simples e inicializado de registro, e podemos 
encapsular esse conhecimento em nossas classes de registro de modo que o resto de nosso 
aplicativo fique isolado da interface limite do log4j. 


Os testes de aprendizagem são melhores que de graça 


Os testes de aprendizagem acabam não custando nada. Tivemos de aprender sobre a API 
mesmo, e escrever aqueles testes foi uma forma fácil e separada de obter o conhecimento que 
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conseguimos. Os testes de aprendizagem sào experimentos precisos que ajudam a aumentar 
nosso entendimento. 

Esses testes nào só saem de graça como geram um retorno positivo de nosso investimento. 
Quando houver nossas distribuições daquele pacote externo, podemos executar os testes para ver 
se há diferenças nas atividades. 

Os testes de aprendizagem verificam se os pacotes de terceiros que estamos usando se 
comportam como desejamos. Uma vez integrados, não há garantias de que o código se manterá 
compatível com as nossas necessidades. Os autores originais sofrerão pressão para alterarem 
seus códigos para satisfazer suas próprias necessidades. Eles consertarão bugs e adicionarão 
novos recursos. Cada distribuição vem com um novo risco. Se o pacote for alterado de uma 
forma que fique incompatível com nossos testes, descobriremos de imediato. 

Você precise ou não do conhecimento proporcionado pelos testes de aprendizagem, deve-se 
definir um limite claro por meio de uma série de testes externos que experimentem a interface da 
mesma forma que seu código faria. Sem esses testes limite para facilitar a migração. poderemos 
ficar tentados a manter por mais tempo do que deveriamos a versão antiga. 


O uso de código que não existe ainda 


Há outro tipo de limite, um que separa o conhecido do desconhecido. Geralmente há lugares 
no código onde nosso conhecimento parece sumir. Às vezes, o que está do outro lado nos é 
desconhecido (pelo menos agora). Às vezes, optamos não olhar além do limite. 

Alguns anos atrás fiz parte do time do desenvolvimento de software para um sistema de 
comunicação de rádios. Havia um subsistema, o “Transmissor”. que eu pouco sabia a respeito, 
€ as pessoas responsáveis por ele não tinham ainda definido sua interface. Não queríamos ficar 
parados, então começamos a trabalhar longe daquela parte desconhecida do código. 

Sabíamos muito bem onde nosso mundo terminava e onde começava o novo. Conforme 
trabalhávamos, às vezes chegávamos a esse limite entre os dois mundos. Embora névoas e 
nuvens de ignorância ofuscassem nossa visão para além do limite, nosso trabalho nos mostrou o 
que queríamos que fosse a interface limite. Desejávamos dizer ao transmissor algo assim: 


Configure o transmissor na frequência fornecida e emita uma representação analógica dos 
dados provenientes desde fluxo. 


Não tínhamos ideia de como isso seria feito, pois a API ainda não havia sido desenvolvida. 
Portanto, decidimos trabalhar nos detalhes depois. 

Para não ficarmos parados, definimos nossa própria interface. Demos um nome fácil de 
lembrar, como Transmitter. Criamos um método chamado transmit que pegava uma 
frequência e um fluxo de dados. Essa era a interface que gostariamos de ter. 

O bom de criar a interface que desejamos é que podemos controlá-la. Isso ajuda a manter o 
código do lado do cliente mais legível e centralizado na função para a qual fora criado. 

Na Figura 8.2 você pode ver que preenchemos as classes do CommunicationsController 
a partir da API do transmitter, a qual não controlávamos e havia sido definida. Ao usar 
nossa própria interface para o aplicativo, mantivemos limpo e expressivo nosso código 
do CommunicationsController. Uma vez definida a API do transmitter, criamos o 
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Transmitteradapter para fazer a conexão. O ADAPTER’ encapsulou a interação com a API 
e forneceu um único local para ser modificado se a API for aperfeiçoada. 


<<futuro>> 
API do Transmitter 


Figura 8.2: Adivinhando deverá ser o transmitter 


Esse modelo também nos dá um seam? bastante conveniente no código para testarmos. 
Ao usar um FakeTransmitter (transmissor falso) adequado, podemos testar as classes 
do CommunicationsController. Além de podermos criar testes limite uma vez que temos а 
TransmitterAPI para garantir que estamos usando corretamente а APL 


Limites limpos 


Coisas interessantes ocorrem nos limites. A alteração é uma delas. Bons projetos de software 
acomodam modificações sem muito investimento ou trabalho. Quando usamos códigos que 
estão fora de controle, deve-se dar uma atenção especial ao nosso investimento e garantir que 
uma mudança futura não seja muito custosa. 

O código nos limites precisa de uma divisão clara e testes que definem o que se deve esperar. 
Devemos evitar que grande parte de nosso código enxergue as particularidades dos de terceiros. 
É melhor depender de algo que você controle do que pegar algo que acabe controlando você. 
Lidamos com os limites de códigos externos através de alguns poucos lugares em nosso código 
que fazem referência a eles. Podemos empacotá-los como fizemos com o Map, ou talvez usar um 
ADAPTER para converter nossa interface perfeita na que nos for fornecida. De qualquer forma, 
nosso código se comunica melhor conosco, provê uso consistente interno pelo limite e possui 
poucos pontos para serem mexidos quando o código externo sofrer alteração. 
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Nossa profissão evoluiu bastante ao longo dos últimos dez anos. Em 1997 não se ouvia falar 
em Desenvolvimento Dirigido a Testes (TDD, sigla em inglês). Para a grande maioria de nós, 
os testes de unidade eram um pequeno pedaço de código descartável que escreviamos para nos 
certificar que nossos programas funcionavam. Meticulosamente criávamos nossas classes e 
métodos e, então, improvisávamos um código para testá-los. Tipicamente, isso envolvia um 
programa simples de controle que nos permitisse interagir manualmente com o programa que 
havíamos escrito. 

Lembro-me de ter criado em meados da década de 1990 um programa em C++ para um 
sistema integrado em tempo real. Era um simples contador com a seguinte assinatura: 
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void Timer::ScheduleCommand(Command* theCommand, int milliseconds) 


A idéia era simples: o método execute de Command seria executado numa nova thread após 
um número específico de milésimos de segundos. O programa era como testá-lo. 

Criei um simples programa de controle que esperava alguma ação no teclado. Sempre que um 
caractere era pressionado, ele agendaria um comando que escreveria o mesmo caractere cinco 
segundos depois. Então eu digitava uma melodia no teclado e esperava que cla fosse reproduzida 
na tela cinco segundos depois. 


“Eu ... quero-uma-mulher ... igual ... a-com-quem-me-ca sei... querido ... ра... pai” 


Realmente cantei essa melodia enquanto digitava o ponto “.” e, então, a cantava novamente 
quando aparecia na tela. 

Esse era meu teste! Depois que o vi funcionar e o mostrei aos meus colegas, joguei o código 
do teste fora. 

Como eu disse, nossa profissão evoluiu. Atualmente eu criaria um teste que garantisse que 
cada canto do código funcionasse como eu esperava. Eu isolaria meu código do resto do sistema 
operacional em vez de apenas invocar as funções padrão de contagem; simularia aquelas funções 
de modo que eu tivesse controle absoluto sobre o tempo; agendaria comandos que configurassem 
flags booleanas; e, então, adiantaria o tempo, observando as flags e verificando se elas mudavam 
de falsas para verdadeiras quando eu colocasse o valor correto no tempo. 

Quando pego uma coleção de testes para passar adiante. eu me certifico se eles são adequados 
para serem executados por qualquer pessoa que precise trabalhar com o código, e se eles e o 
código estavam juntos no mesmo pacote de origem. 

Isso, progredimos bastante, mas ainda podemos ir mais longe. Os movimentos do Agile e 
do TDD têm incentivado muitos programadores a criarem testes de unidade automatizados, c 
muitos outros estão se unindo a cada dia. Mas nessa correria para adicionar testes ao nosso 
ofício, muitos programadores têm se esquecido de alguns dos pontos mais sutis e importantes de 
se escrever bons testes. 


As três leis do TDD 


Hoje em dia todos sabem que o TDD nos pede para criar primeiro os testes de unidade antes do 
código de produção. Mas essa regra é apenas o início. Considere as trés leis’ abaixo: 


Primeira Lei Não se deve escrever o código de produção até criar um teste de unidade de falhas. 
Segunda Lei Não se deve escrever mais de um teste de unidade do que o necessário para falhar, 
e não compilar é falhar. 

Terceira Lei Não se deve escrever mais códigos de produção do que o necessário para aplicar o 
teste de falha atual. 


Lacus mie ci ictum Main bie Аана TRE ee ee CUL TA Na) on. SEIO 
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Essas três leis lhe colocam numa rotina que talvez dure trinta segundos. Os testes e o código 
de produção são escritos juntos. com os testes apenas alguns segundos mais adiantados. 

Se trabalharmos dessa forma, criaríamos dezenas de testes a cada dia, centenas a cada mês 
e milhares a cada ano; os testes cobririam praticamente todo o nosso código de produção. 
O tamanho completo desses testes, que pode competir com o tamanho do próprio código de 
produção, pode apresentar um problema de gerenciamento intimidador. 


Como manter os testes limpos 


Háalguns anos, pedi para orientar uma equipe que tinha decidido explicitamente que seus códigos 
de testes não deveriam ser preservados segundo os mesmos padrões de qualidade que seu código 
de produção. Eles se deram autorização para violar as leis em seus testes de unidade. “Rápida e 
porcamente” era o lema. As variáveis não precisavam de nomes bem selecionados, as funções 
de teste não tinham de ser curtas e descritivas. Os códigos de testes não precisavam ser bem 
desenvolvidos e divididos de modo pensado. Se que o resto dos códigos de testes funcionasse e 
que cobrisse o código de produção, já era o suficiente. 

Alguns de vocés lendo isso talvez simpatizem com tal decisão. Talvez, lá no passado, você criou 
testes tipo aquele que fiz para aquela classe Timer. É um grande passo ir da criação daquele tipo de 
teste descartável para uma coleção de testes de unidade automatizados. Portanto, assim como a equipe 
que eu orientara, você talvez decida que testes feitos “porcamente” sejam melhores do que nada. 

O que aquela equipe não percebera era que ter testes daquele tipo é equivalente, se não pior, 
a não ter teste algum. O problema é que muitos testes devem ser alterados conforme o código de 
produção evolui. Quanto pior o teste, mais dificil será de mudá-lo. Quanto mais confuso for o 
código de teste, são maiores as chances de você levar mais tempo espremendo novos testes para 
dentro da coleção do que na criação do código de produção. Conforme você modifica o código 
de produção, os testes antigos começam a falhar e a bagunça no código de teste dificulta fazê- 
los funcionar novamente. Sendo assim, os testes começam a ser vistos como um problema em 
constante crescimento. 

De distribuição em distribuição, o custo de manutenção da coleção de testes de minha equipe 
aumentou. Com o tempo, isso se tornou a maior das reclamações entre os desenvolvedores. Quando 
os gerentes perguntaram o motivo da estimativa de finalização estava ficando tão grande, os 
desenvolvedores culparam os testes. No final, foram forçados a descartar toda coleção de testes. 

Mas, sem uma coleção de testes, eles perderam a capacidade de garantir que, após alterações 
no código-fonte, ele funcionasse como o esperado e que mudanças em uma parte do sistema não 
afetariam as outras partes. Então, a taxa de defeitos começou a crescer. Conforme aumentava o 
número de bugs indesejáveis, começaram a temer fazer alterações e pararam de limpar o código 
de produção porque temiam que isso poderia fazer mais mal do que bem. O código de produção 
começou a se degradar. No final das contas, ficaram sem testes, com um código de produção 
confuso e cheio de bugs, com consumidores frustrados e o sentimento de que o esforço para 
criação de testes não valeu de nada. 

De certa forma estavam certos. Tal esforço tinha sido em vão. Mas fora decisão deles permitir 
que os testes ficassem uma bagunça е se tornasse а origem do fracasso. Se tivessem mantido os 
testes limpos, o esforço para a criação dos testes não teria os deixado na mão. Posso dizer isso 
com um pouco de certeza, pois participei de tudo, e já orientei muitas equipes que obtiveram 
sucesso com testes de unidade limpos. 
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A moral da história é simples: Os códigos de testes são tão importantes quanto o código de 
produção. Ele não é componente secundário. Ele requer raciocinio, planejamento e cuidado. É 
preciso mantê-lo tão limpo quanto o código de produção. 


Os testes habilitam as “-idades” 


Se não mantiver seus testes limpos, irá perdê-los. E, sem eles, você perde exatamente o que 
mantém a flexibilidade código de produção. Isso mesmo, você leu certo. São os testes de 
unidade que mantêm seus códigos flexíveis, reutilizáveis e passíveis de manutenção. A razão é 
simples. Se você tiver testes, não terá medo de alterar o código! Sem os testes, cada modificação 
pode gerar um bug. Não importa o grau de flexibilidade de sua arquitetura ou de divisão de seu 
modelo. pois sem os testes você ficará relutante em fazer mudanças por temer gerar bugs não 
detectados. 

Mas com os testes esse medo praticamente some. Quanto maior a cobertura de seus testes, 
menor o medo. Você pode fazer mudanças quase sem penalidade ao código que tenha uma 
arquitetura emaranhada e um modelo confuso e opaco. De fato, você pode improvisar essa 
arquitetura e esse modelo sem temer! 

Portanto, ter uma coleção de testes de unidade automatizados que cubram o código de 
produção é o segredo para manter seu projeto e arquitetura os mais limpos possíveis. Os testes 
habilitam todas as “-idades”, pois eles possibilitam as alterações. 

Dessa forma, caso seus testes estejam ruins. então sua capacidade de modificar seu código fica 
comprometida e você começa a perder a capacidade de melhorar a estrutura dele. Quanto piores 
forem os testes, pior o código se torna. No final, você perde os testes e seu código se degrada. 


Testes limpos 


O que torna um teste limpo? Três coisas: legibilidade, legibilidade e legibilidade. Talvez isso 
seja até mais importe nos testes de unidade do que no código de produção. O que torna os testes 
legíveis? O mesmo que torna todos os códigos legíveis: clareza, simplicidade e consistência de 
expressão. Num teste você quer dizer muito com o mínimo de expressões possíveis. 

Considere o código do FitNesse na Listagem 9.1. Esses três testes são difíceis de entender 
€ certamente podem ser melhorados. Primeiro, há uma quantidade terrível de código duplicado 
[G5] nas chamadas repetidas a addPage e assertSubString. Mais importante ainda é que este código 
está carregado de detalhes que interferem na expressividade do teste. 


Listagem 9-1 
SerializedPageResponderTest java 


void testGetPageHieratchyAsXmli) throws Exception 


publi 
t 


crawler.addPageiroot, PathParser.parse|"PageOne")]; 
Crawler.addPagelrcot, PathParser.parse("PageOne.ChildOne*!); 
crawler.addPageiroot, PathParser .parse(*PageTwo")); 


Testes Limpos 


125 


Listagem 9-1 (continuação) 
SerializedPageResponderTest java 


request .setResource("root"); 
request .addInput ("type", "pages"}; 
Responder responder = new SerializedPageResponder |) ; 
SimpleResponse response = 
(SimpleResponse) responder .makeResponse ( 
new FitNesseContext (root), request); 
String xml = response.getContent (); 


assertEquals ("text /xml", response.getContentType()); 
assert SubString("<name>PageOne</name>", xml); 
assertSubString ("<name>PageTwo</name>", xml); 
assert SubString("<name>ChildOne</name>", xml); 


) 


throws Exception 

í 
WikiPage pageOne 
crawler.addPage (rc: 
crawler.addPage(root, PathParser.parse(*PageTwo")); 


crawler.addPage(root, PathPars 


PageData data = pageOne.getDataí); 
WikiPageProperties properties = data.getProperties(); 


symLinks.set ("SymPage", "PageTwo*); 
pageOne.commit (data) ; 


request .setResourcei"root"}): 
request .addInput ("type", “pages*); 
Responder responder = new SerializedFageResponder (); 
SimpleResponse response = 
(SimpleResponse) responder .makeResponse ( 
new FitNesseContext (root), request); 
String xml = response.getContent () ; 


assertEquals(*text/xml", response.get 
assertSubString i "<name>PageOne</name>' 
assert SubString(*<name>PageTwo</name>", xml); 
assert SubString (*<name>Chi ldOne</name>", xml}; 
assertNot Substring ("SymPage", xml); 

} 


public void testGetDataAslitml|) throws Exception 
[ 


request . set Resource ("TestPageone” ) ; 
request .addInput (*type", "data"!; 


public void testGetPageHieratchyAsXmlDoesntContainSymbolicLink: 


.рагве!"Р. 
‚ PathParser.parse(*FageOne.ChildOne*!]; 


WikiPageProperty symLinks = properties .set (SymbolicPage. PROP 


crawler.addPage (root, PathParser.parse("TestPageQne"), “test 


Por exemplo, veja as chamadas para PathParser. Elas transformam strings em instâncias 
PagePath pelos crawler. Essa transformação é completamente irrelevante na execução do 
teste e serve apenas para ofuscar o objetivo. Os detalhes em torno da criação do responder e a 
definição do tipo de response também são apenas aglomerados. E tem a inepta forma pela qual 
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é construído URL requisitado a partir de um resource e um parâmetro. (Ajudei a escrever esse 
código, portanto me sinto completamente no direito de criticá-lo). 

No final, esse código não foi feito para ser lido. O pobre leitor é inundado com um monte de 
detalhes que devem ser entendidos antes que os testes façam algum sentido. Agora, considere os 
testes improvisados na Listagem 9.2. Eles fazem exatamente o mesmo, mas foram refatorados 
de uma forma muito mais clara e descritiva. 


Listagem 9-2 
SerializedPageResponderTest.java (refatorado) 


public void testGetPagelierarchyAsXml() throws Exception ( 
makePages("PageCne", "PageOne.ChildOne'. *PageTwo"); 


submitRequesti'root", “type:pages"); 
assertResponseIsXML() ; 
assertResponseContains ( 
"«name»PageOne«/name»*, '«name»PageTwo«/name»', "«name»ChildOne«/name»" 


} 
public void testSymbolicLinksAreNotInxmlPageHierarchy() thros 


WikiPage page = makePagel"PageOne"); 
makePages("PageOne.ChildOne*, *PageTwo"): 


Exception ( 


addLinkTo(page, "PageTwo', "SymPage"); 
submitRequest (*root", *type:pages'!; 


assertResponseIsXML(); 
assertResponseContains ( 
*<name>PageOne</name>", "«name»PageTwoc/name»*, "«name»ChildOne«/name»" 
N 
assertResponseDoesNotContain і "ЅупРаде") ; 


public void testGetDataAsXml() throws Excej 
makePageWithContent ("TestPageOne", "test 


submirRequest ("TestPageOne", "type:dara*]; 


assercResponseIsXML() ; 
assertResponseContains (“test раде", "<Test"); 
) 


L- 


A estrutura desses testes tomou óbvio o padrão CONSTRUIR-OPERAR-VERIFICAR-. 
Cada um dos testes está claramente dividido em três partes. A primeira produz os dados do teste, 
a segunda opera neles e a terceira verifica se a operação gerou os resultados esperados. 

Note que a grande maioria dos detalhes maçantes foi eliminada. Os testes vão direto ao 
ponto e usam apenas os tipos de dados e funções que realmente precisam. Quem ler esses 
testes dev ser capaz de descobrir rapidamente o que fazem, sem se deixar enganar ou ficar 
sobrepujado pelos detalhes. 


er JT 1 Рае 
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Linguagem de testes específica ao domínio 


Os testes na Listagem 9.2 mostram a técnica da construção de uma linguagem específica a um 
domínio para seus testes. Em vez de usar as APIs que os programadores utilizam para manipular o 
sistema, construímos uma série de funções e utilitários que usam tais APIs e que tornam os testes 
mais convenientes de se escrever e mais fáceis de ler. Esses funções e utilitários se tornaram uma 
API especializada usada pelos testes. Eles testam a linguagem que os programadores usam para 
auxiliá-los a escrever seus testes e para ajudar àqueles que precisem ler esses testes mais tarde. 

Essa API de teste não foi desenvolvida de uma só vez; ela evoluiu de uma continua refatoração 
de códigos de testes que ficaram demasiadamente ofuscados por detalhes confusos. Assim como 
você me viu refatorar a Listagem 9.1 para Listagem 9.2, desenvolvedores disciplinados também 
refatoram seus códigos de teste para formas mais sucintas e expressivas. 


Um padrão duplo 


De um certo modo, a equipe que mencionei no início deste capítulo estava certa. O código dentro 
da API de teste tem um conjunto diferente de padrões de engenharia em relação ao código de 
produção. Ele pode ser simples, sucinto e expressivo, mas não precisa ser mais eficiente do 
que o do código de produção. Apesar de tudo, ele roda num ambiente de teste, e não de um de 
produção, e esses dois ambientes possuem requisitos diferentes. 

Considere o teste na Listagem 9.3 que escrevi como parte de um sistema de controle de 
ambiente que eu estava fazendo a prototipagem. Sem entrar em detalhes, posso lhe dizer que o 
teste verifica se o alarme de temperatura baixa, o aquecedor e o ventilador estão todos ligados 


quando a temperatura estiver “fria demais”. 


Listagem 9-3 
EnvironmentControllerTest. java 
atest 
public void tun armatThreashold(! throws Exception { 
hw.setTemp (W LD); 


controller.t 
assertTrue (hw.heaterState()); 
assertTrue (hw.blowerState()); 
assertFalse (hw.coolerState()); 
assertFalse(hw.hiTempAlarm()); 
assertTrue (hw. loTempAlarm()); 


Há, é claro, muitos detalhes aqui. Por exemplo, o que faz a função tic? Na verdade, prefiro 
que você não se atenha a isso ao ler esse teste, mas que se preocupe apenas se você concorda ou 
não se o estado final do sistema é consistente com a temperatura sendo “fria demais”. 

Note que, ao ler o teste, seus olhos precisam ler e reler entre o nome do estado sendo verificado 
e a medida do estado sendo verificado. Você vê heaterState e, então, seus olhos deslizam 
para a direita, para assert True. Você vê coolerState e seus olhos devem se voltar para a 
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esquerda. para assertFalse. Isso é entediante e falível, além de dificultar a leitura do teste. 
Aperfeiçoei a legibilidade deste teste consideravelmente na Listagem 9.4. 


Listagem 9-4 
EnvironmentControllerTest.java (refatorado) 


GTest 
public void turnOnLoTempAlarmAtThreshold() throws Exception ( 
wayTooCold(); 
assertEquals ("HBchL", hw.getState()); 


É claro que criei uma função wayTooCold para ocultar o detalhe da função tic. Mas o que 
se deve notar é a estranha string em assertEquals. As letras maiúsculas significam “ligado” e 


as minúsculas “desligado”, e elas sempre seguem a seguinte ordem: (heater, blower, cooler, hi-temp- 
alarm, lo-temp-alarm}. 


Mesmo que esse código esteja perto de violar a regra do mapeamento mental”, neste caso 
parece apropriado. Note que. uma vez conhecendo o significado, seus olhos deslizam sobre a 
string e você logo consegue interpretar os resultados. Torna-se quase uma satisfação ler o teste. 
Dé uma olhada na Listagem 9.5 e veja como é fácil entender esses testes. 


Listagem 9-5 
EnvironmentControllerTest. java (seleção maior) 
@Test 
public void turnOnCoolerAndBlowerifTcoHot () throws Exception ( 


tooHotí); 
assertEquals(*hBChl*, hw.getState!]); 


GTest 
public void turnOnHiTempAlarmatThreshold!) throws Exception { 
wayTooHot () ; 


assertEquals ("hBCHI", hw.getState(]); 
) 


8Test 

public void turnOnLoTempAlarmAtThresholdi) throws Exception [ 
wayTooCold(); 
assertEqualsi'HBchL', hw.getState()); 


A função getState está na Listagem 9.6. Note que esse código não é muito eficiente. Para isso, 
provavelmente eu deveria ter usado um StringBuffer. 


Prep de a 
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Listagem 9-6 
MockControlHardware. java 


public String getState() ( 
String state 


state heater ? "Н" : 

state += blower ? "В" 

state += cooler ? "С" 

state += hiTempAlarm ? "H" ch"; 
state += loTempAlarm ? "L" ; "1"; 


return state; 


As StringBuffers são um pouco feias. Mesmo no código de produção irei evitá-las se o custo for 
pequeno; e você poderia argumentar que o custo do código na Listagem 9.6 é bastante pequeno. 
Contudo, esse aplicativo está claramente em um sistema integrado em tempo real, e é mais 
provável que os recursos do computador e da memória sejam muito limitados. O ambiente de 
teste, entretanto, não costuma ter limitações alguma. 

Essa é a natureza do padrão duplo. Há coisa que você talvez jamais faça num ambiente de 
produção que esteja perfeitamente bem em um ambiente de teste. Geralmente, isso envolve 
questões de eficiência de memória e da CPU. Mas nunca de clareza. 


Uma confirmação por teste 


Há uma escola de pensamento! que diz que cada função de teste em um teste JUnit deve ter um e 
apenas uma instrução de confirmação (assert). Essa regra pode parecer perversa, mas a vantagem 
pode ser vista na Listagem 9.5. Aqueles testes chegam a uma única conclusão que é fácil e rápida 
de entender. 

Mas e a Listagem 9.2? Parece ilógico que poderíamos de alguma forma facilmente adicionar 
a confirmação se a saída está em XML e se ela contém certas substrings. Entretanto, podemos 
dividir o teste em dois, cada um com sua própria confirmação, como mostra a Listagem 9.7. 


Listagem 9-7 
SerializedPageResponderTest.java (Confirmação Única) 


public void testGetPageHierarchyAsXml() throws Exception { 
givenPages("PageOne”, "PageOne.ChildOne*, *FageTwo"]; 


whenRequesLIsIssued(*root", "type:pages"); 


thenResponseShou]dBeXML ( ) ; 


publ 
givenPages(*PageOne*, "PageOne.ChildOne*, "Fi 


void testGetPageHierarchyBasRightTags() throws 
Two" 


whenRequestIsIssued(*root*, "type:pages']; 

thenResponseShouldContain( 
"«name»PageOne«/name»', "«name»PageTwo«/name»", '«name»ChildOne«/name»" 
D 

} 
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Note que mudei os nomes das funções para usar a convenção comum dado-quando-então. Isso 
facilita ainda mais a leitura dos testes. Infelizmente, como pode ver, dividir os testes pode gerar 
muito código duplicado. 

Podemos usar o padrão Template Method para eliminar a duplicação e colocar as partes 
dado/quando na classe base e as partes então em derivadas diferentes. Ou poderiamos criar uma 
classe de teste completamente separada e colocar as partes dado e quando na função Before e 
as partes quando em cada função @Test. Mas isso parece muito trabalho para uma questão tão 
pequena. No final, prefiro as confirmações múltiplas na Listagem 9.2. 

Acho que a regra da confirmação única é uma boa orientação”. Geralmente tento criar uma 
linguagem de teste para um domínio específico que a use, como na Listagem 9.5. Mas não tenho 
receio de colocar mais de uma confirmação em um teste. Acho que a melhor coisa que podemos 
dizer é que se deve minimizar o número de confirmações em um teste. 


Um único conceito por teste 


Talvez a melhor regra seja que desejamos um único conceito em cada função de teste. Não 
queremos funções longas que saiam testando várias coisas uma após a outra. A Listagem 9.8 
é um exemplo disso. Esse teste deve ser dividido em três independentes, pois ele testa três 
coisas distintas. Juntá-los todos na mesma função obriga o leitor compreender o objetivo de cada 
função presente e o que ela testa. 


Listagem 9-8 


* Miscellaneous tesi 


publ 


s for the addMonths() method. 


с void testAddMonths() { 
SerialDate dl = SerialDate.createInstance(31, 5, 2004); 


SerialDate d2 - SerialDate.addMonth: 
assertEquals(30, d2.getDayOfMonth!)) ; 
assertEqualsi6, gerMonth()); 
assertEquals(2004, d2.getYYYY(); 


1, dl); 


=o 


SerialDate d3 = SerialDate.addMonths(2, dl); 
assertEquals(31, 43.getDayOfMonth(}): 
assertEquals(7, d3.getMonth()); 
assertEquals(2004, d3.getYYYY()); 


SerialDate d4 = SerialDate.addMonths!l, SerialDate.addMonths(1, dl)); 
assertEquals(30, d4.getDayOfMonth()) ; 

assertkquals(7, d4.getMonth()); 

assertEquals(2004, d4.getYYYY()): 


As trés funcóes de teste devem seguir provavelmente assim: 


* Dado o ültimo dia de um més com 31 dias (como maio): 
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1. Quando você adicionar um mês cujo último dia seja o 30º (como junho), então a data deverá 
ser o dia 30 daquele mês, e não a 31. 


2. Quando você adicionar dois meses àquela data cujo último dia seja o 31º, então a data deverá 
ser o dia 31. 


* Dado o último dia de um més com 30 dias (como junho): 
1. Quando você adicionar um més cujo último dia seja o 31º, então a data deverá ser dia 30 e nào Sl. 


Explicado dessa forma, vocé pode ver que há uma regra geral oculta nos testes diversos. Ao incrementar 
o més, a data não pode ser maior do que o último dia daquele mês. Isso implica que incrementar o mês 
em 28 de fevereiro resultaria em 28 de março. Esse teste está faltando e seria útil criá-lo. 

Portanto, não são as confirmações múltiplas em cada seção da Listagem 9.8 que causa o problema. 

É o fato de que há mais de um conceito sendo testado. Assim, provavelmente, a melhor regra scja 
minimizar o número de confirmações por conceito e testar apenas um conceito por função de teste. 


FLR.S.T: 


Testes limpos seguem outras cinco regras que formam o acrônimo em inglês acima (Fast, 
Independent, Repeatable, Self-validating, Timely): 


Rapidez os testes devem ser rápidos. Devem executar com rapidez. Quando os testes rodam 
devagar, você não desejará executá-los com frequência. E, consequentemente. não encontrará 
problemas cedo o bastante para consertá-los facilmente. E você não se sentirá livre para limpar 
o código, que acabará se degradando. 


Independência os testes não devem depender uns dos outros. Um teste não deve configurar as 
condições para o próximo. Você deve ser capaz de executar cada teste de forma independente е 
na ordem que desejar. Quando eles dependem uns dos outros. se o primeiro falhar causará um 
efeito dominó de falhas, dificultando o diagnóstico e ocultando os defeitos abaixo dele. 


Repetitividade deve-se poder repetir os testes em qualquer ambiente. Você deve ser capaz de 
efetuar testes no ambiente de produção, no de garantia de qualidade e no seu notebook enquanto 
volta para casa de trem sem uma rede disponível. Caso seus testes não possam ser repetidos em 
qualquer ambiente, então você sempre terá uma desculpa para o motivo das falhas. E também 
perceberá que não consegue rodar os testes fora o ambiente adequado. 


Autovalidação os testes devem ter uma saída booleana. Obtenham ou não êxito, você não deve 
ler um arquivo de registro para saber o resultado. Você não deve ter de comparar manualmente 
dois arquivos texto para ver se os testes foram bem sucedidos. Se os testes não possuírem 
autovalidação, então uma falha pode se tornar subjetiva, e executar os testes pode exigir uma 
longa validação manual. 


S. Materiais de Treinamento da Object Mentor. 
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Pontualidade os testes precisam ser escritos em tempo hábil. Devem-se criar os testes de unidade 
imediatamente antes do código de produção no qual serão aplicados. Se criá-los depois, o teste 
do código de produção poderá ficar mais difícil. Ou talvez você ache que um pouco do código 
de produção seja complexo demais para testar. Ou talvez você não crie o código de produção de 
maneira que possa ser testado. 


Conclusão 


Aqui abordamos apenas o início deste tópico. De fato, acho que deveria ter um livro inteiro 
sobre Testes limpos. Os testes são tão importantes para a saúde de um projeto quanto o código 
de produção. Talvez até mais, pois eles preservam e aumentam a flexibilidade, capacidade de 
manutenção e reutilização do código de produção. Portanto, mantenha seus testes sempre limpos. 
Trabalhe para torná-los sucintos e expressivos. Invente APIS de teste que funcionem como uma 
linguagem específica a um domínio que lhe ajude a criar seus testes. 

Se deixar os testes de degradarem, seu código também irá. Mantenha limpos os seus testes. 
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Classes 


com Jeff Langr 


Hui 


E 
Fs 


Até agora, este livro se focou em como escrever bem linhas e blocos de código. Mergulhamos 
na composição apropriada para funções e como elas se interrelacionam. Mas apesar de termos 
falado bastante sobre a expressividade das instruções do código e as funções que o compõem, 
ainda não teremos um código limpo até discutirmos sobre os níveis mais altos da organização do 
código. Vamos fala agora sobre classes limpas. 
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Organização das classes 


Seguindo uma convenção padrão Java, uma classe deve começar com uma lista de variáveis. 
As públicas (public), estáticas (static) e constantes (constants), se existirem, devem 
vir primeiro. Depois vêm as variáveis estáticas privadas (private static), seguidas pelas 
instâncias privadas. Raramente há uma boa razão para se ter uma variável pública (public). 

As funções públicas devem vir após a lista de variáveis. Gostamos de colocar as tarefas 
privadas chamadas por uma função pública logo depois desta. Isso segue a regra de cima para 
baixo e ajuda o programa a ser lido como um artigo de jornal. 


Encapsulamento 


Gostaríamos que nossas variáveis e funções fossem privadas, mas não somos radicais. 

Às vezes, precisamos tornar uma variável ou função protegida (protected) de modo que 
possa ser acessada para testes. Para nós. o teste tem prioridade. Se um teste no mesmo pacote 
precisa chamar uma função ou acessar uma variável, a tornaremos protegida ou apenas no 
escopo do pacote. Entretanto, primeiro buscaremos uma forma de manter a privacidade. Perder 
o encapsulamento sempre é o último recurso. 


As classes devem ser pequenas! 


A primeira regra para classes é que devem ser pequenas. A segunda é que devem ser menores 
ainda. Não, não iremos repetir o mesmo texto do capítulo sobre Funções. Mas assim como com as 
funções, ser pequena também é a regra principal quando o assunto for criar classes. Assim como 
com as funções, nossa questão imediata é “O quão pequena?”. Com as funções medimos o tamanho 
contando as linhas fisicas. Com as classes é diferente. Contamos as responsabilidades'. 

A Listagem 10.1 realça uma classe, a SuperDashboard, que expõe cerca de 70 métodos públicos. 

A maioria dos desenvolvedores concordaria que ela é um pouco grande demais em tamanho. 
Outros diriam que a SuperDashboard é uma “classe de deus”. 


Listagem 10-1 
Responsabilidades em excesso 


public class SuperDashboard extends JFrame implements MetaDat: 
Ш String getCustomizerLanguagePathi) 

void setSystemConfigPath(String systemConfigPath) 
String getSystemConfigDoci 
void setSystemConfigDocumei 
boolean gerGurustate() 
boolean getNovicestate|] 
boolean getOpensi 
р с void shewObject (MetaObject object) 
public void showProgress (String s 


t0 
String systemConfigDocument) 


1 fRDDI. 
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Listagem 10-1 (continuação) 
Responsabilidades em excesso | 


public boolean isMetadataDirty() 
public void setIsMetadataDirty (boolean isMetadataDirty) 
public Component getLastFocusedComponent () 
public void setLastFocused (Component lastFecused) 
public void setMouseSelectState(boolean isMouseSelected) 
boolean isMouseselected() 
LanguageManager getLanguageManager () 
Project ge ject () 
Project getFirstProject i) 
Project getLast Project () 
String getNewProjectName() 
void secComponentSizes (Dimension dim! 
String getCurrentDir() 
void setCurrentDir (String newDirl 
© void updateStatus(int dotPos, int markPos) 
Class[] getDataBaseClasses() 
MetadaraFeeder getMetadataFeeder () 
void adáProject (Project project) 
boolean serCurrentProject (Project project) 
boolean removeProject (Project project! 
MetaProjectHeader getProgranMetadata() 
void resetDashboard() 
Project loadProject (String fileName, String projectName) 
void setCanSaveMetadata (boolean canSave) 
MetaObject getSelectedObject () 
void deselectObjects() 
void setProject (Project proj 
void editorAction(String 
void setModetint mode) 
FileManager getFileManager() 
void setFileManager (FileManager fileManager) 
public CorfigManager getConfigManager () 
public void setConfigManager (ConfigManager configManager) 
public ClassLoader getClassLoader () 
public void setClassLoader (ClassLoader classLoader) 
public Properties getProps() 
public String getUserkome () 
public String getBaseDiri) 
public int getMajorVersionNumber í) 
pubiic int getMinorVersicnNumber () 
public int getBuildNumber!) 
public MetaO0bject pasting( 
MetaObject target, MetaObject pasted, MetaProject project) 
public void processMenuItema (MetaObject metadbject ) 
public void processMenuSeparators (MetaObject metadbject) 
public void processTabPages(MetaObject metaObject) 
public void processPlacement (MetaObject object) 
public void processCreateLayout (Metadbject object) 
public void updateDisplayLayer (MetaObject object, int layerIndex) 
public void propertyEditedRepaint (Мегаоьјесс object) 
public void processDeleteObject (MetaObject object) 
public boolean getAttachedToDesigner () 
public void processProjectChangedState boolean hasProjectChanged) 
public void processObjectNameChanged (MetaOdject object) 
public void runProject (| 


t) 
ionName, ActionEvent event) 
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Listagem 10-1 (continuação) 
Responsabilidades em excesso 


public void setAcowDragging(boolean allowDragging) 

public boolean allowDraggingi) 

public boolean isCustomizing() 

public void setTitle(String title) 

public IdeMenuBar get IdeMenuBar () 

public void showHelper(MetaObject metaObject, String propertyName) 
/ ... many non-public methods follow ... 


Mas e se SuperDashboard possuísse apenas os métodos da Listagem 10.2? 


Listagem 10-2 
Pequena o suficiente? 


public class SuperDashboard extends JFrame implements MetaDataUser 
public Component gerLastFocusedComponent () 
public void setLastFocused (Component lastFocused) 
pubiic int getMaj nNumber ( j 
public int getMinorVersionNumber () 
public int getBuildNumber () 


Cinco não é muito, é? Neste caso é, pois apesar da pequena quantidade de métodos, a 
SuperDashboard possui muitas responsabilidades. 

O nome de uma classe deve descrever quais responsabilidades ela faz. Na verdade, selecionar 
um nome é a primeira forma de ajudar a determinar o tamanho da classe. Se não derivarmos um 
nome conciso para ela, então provavelmente ela ficará grande. Quanto mais ambíguo for o nome 
da classe, maiores as chances de ela ficar com muitas responsabilidade. Por exemplo, nomes 
de classes que possuam palavras de vários sentidos, como Processador ou Gerenciador ou 
Super, geralmente indicam um acúmulo lastimável de responsabilidades. 

Devemos também poder escrever com cerca de 25 palavras uma breve descrição da classe, 
sem usar as palavras “se”, “e”, “ou” ou “mas”. Como descreveríamos a SuperDashboard? 
“A SuperDashboard oferece acesso ao componente que foi o último utilizado e também nos 
permite acompanhar os números da versão e da compilação”.O primeiro “e” é uma dica de que 
a classe possui responsabilidades em excesso. 


O Principio da Responsabilidade Única 


O Principio da Responsabilidade Única (SRP, sigla em inglés) afirma que uma classe ou 
módulo deve ter um, e apenas um, motivo para mudar. Este princípio nos dá uma definição 
de responsabilidade e uma orientação para o tamanho da classe. Estas devem ter apenas uma 
responsabilidade e um motivo para mudar. 
Uma classe pequena como essa, a SuperDashboard, na Listagem 10.2, possui duas razões 
para ser alterada. 

Primeiro, ela acompanha a informação sobre a versão, que precisa ser atualizada sempre que 
surgir uma nova distribuição do software. Segundo, ela gerencia os componentes Swing do Java 


2; Pode-se ler io suas atos еше principio cim [РЕР]. 
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(é um derivado do JFrame, a representação do Swing de uma janela GUI de alto nível). Sem 
dúvida iremos querer atualizar o número da versão se alterarmos qualquer código do Swing. mas 
o oposto não é necessariamente verdadeiro: podemos mudar as informações da versão baseando- 
nos nas modificações em outros códigos no sistema. 

Tentar identificar as responsabilidades (motivos para alteração) costuma nos ajudar a 
reconhecer e criar abstrações melhores em nosso código. Podemos facilmente extrair todos 
os três métodos SuperDashboard que lidam com as informações de versão em uma classe 
separada chamada Version. (Veja a Listagem 10.3). A classe Version é um construtor que 
possui um alto potencial para reutilização em outros aplicativos! 


Listagem 10-3 
Classe com responsabilidade única 


public class Version i 
public int getMajorVersionNumber () 
public int getMinorVersionNumber () 
public int getBuildNumber () 


O SRP é um dos conceitos mais importantes no desenvolvimento OO. É também um dos 
mais simples para se entender e aprender. Mesmo assim, estranhamente, o SRP geralmente é 
o princípio mais ignorado na criação de classes. Frequentemente, encontramos classes que faz 
muitas coisas. Por quê? 

Fazer um software funcionar e torná-lo limpo são duas coisas bem diferentes. 

А maioria de nós tem uma mente limitada, por isso, nós tentamos fazer com que nosso código 
possua mais do que organização e clareza. Isso é totalmente apropriado. Manter uma separação de 
questões é tão importante em nossas atividades de programação como em nossos programas. 

O problema é que muitos de nós achamos que já terminamos se o programa funciona. 

Esquecemo-nos da outra questão de organização e de clareza. Seguimos para o próximo problema 
em vez de voltar c dividir as classes muito cheias em outras com responsabilidade únicas. 

Ao mesmo tempo. muitos desenvolvedores temem que um grande número de classes pequenas 
e de propósito único dificulte mais o entendimento geral do código. Eles ficam apreensivos em 
ter de navegar de classe em classe para descobrir como é realizada uma parte maior da tarefa. 

Entretanto, um sistema com muitas classes pequenas não possui tantas partes separadas a 
mais como um com classes grandes. Há também bastante a se aprender num. sistema com poucas 
classes grandes. Portanto, a questão é: você quer suas ferramentas organizadas em caixas de 
ferramentas com muitas gavetas pequenas. cada um com objetos bem classificados e rotulados? 
Ou poucas gavetas nas quais você coloca tudo? 

Todo sistema expansível poderá conter uma grande quantidade de lógica e complexidade. 
O objetivo principal no gerenciamento de tal complexidade é organizá-la de modo que o 
desenvolvedor saiba onde buscar o que ele deseja e que precise entender apenas a complexidade 
que afeta diretamente um dado momento. Em contrapartida, um sistema com classes maiores 
de vários propósitos sempre nos atrasa insistindo que percorramos por diversas coisas que não 
precisamos saber no momento. 

Reafirmando os pontos anteriores: desejamos que nossos sistemas sejam compostos por muitas 
classes pequenas, e não poucas classes grandes. Cada classe pequena encapsula uma única 
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responsabilidade, possui um ünico motivo para ser alterada e contribui com poucas outras para 
obter os comportamentos desejados no sistema. 


Coesão 


As classes devem ter um pequeno número de instâncias de variáveis. Cada método de uma classe 
deve manipular uma ou mais dessas variáveis. De modo geral, quanto mais variáveis um método 
manipular. mais coeso o método é para sua classe. Uma classe na qual cada variável é utilizada 
por um método é totalmente coesa. 

De modo geral, não é aconselhável e nem possível criar tais classes totalmente coesas; 
por outro lado, gostaríamos de obter uma alta coesão. Quando conseguimos, os métodos e as 
variáveis da classe são co-dependentes e ficam juntas como um todo lógico. 

Considere a implementação de uma stack (pilha) na Listagem 10.4. A classe é bastante 
coesa. Dos trés métodos, apenas size () não usa ambas as variáveis. 


Listagem 10-4 
Stack.java - uma classe coesa. 


public class Stac! 
private int topOfStack - 0; 
List<Integer> elements = new LinkedList«Integer»(); 


public int 
return topOf 
} 


(int element) { 


public void p 
topOfStackes; 
elements .add [element ) ; 

public int pop() throws PoppedihenEmpty ( 
if (topOfStack == 0) 

throw new PoppedihenEmpcy () ; 

int element = elements.get (--topofstack) ; 
elements. remove (topóf: д 
return element; 


A estratégia para manter funções pequenas e listas de parâmetros curtas às vezes pode levar 
à proliferação de instâncias de variáveis que são usadas por uma sequência de métodos. Quando 
isso ocorre, quase sempre significa que há pelo menos uma outra classe tentando sair da classe 
maior na qual ela está. Você sempre deve tentar separar as variáveis e os métodos em duas ou 
mais classes de modo que as novas classes sejam mais coesas. 
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Manutenção de resultados coesos em muitas 
classes pequenas 


Só o ato de dividir funções grandes em menores causa a proliferação de classes. Imagine uma 
função grande com muitas variáveis declaradas. Digamos que você deseje extrair uma pequena 
parte dela para uma outra função. Entretanto, o código a ser extraído usa quatro das variáveis 
declaradas na função. Você deve passar todas as quatro para a nova função como parámetros? 

Absolutamente não! Se convertêssemos aquelas quatro variáveis em instâncias de variáveis 
da classe, então poderíamos extrair o código sem passar qualquer variável. Seria fácil dividir a 
função em partes menores. 

Infelizmente, isso também significa que nossas classes perderiam coesão, pois acumulariam 
mais e mais instâncias de variáveis que existiriam somente para permitir que as poucas funções as 
compartilhassem. Mas, espere! Se há poucas funções que desejam compartilhar certas variáveis, isso 
não as torna uma cada uma classe? Claro que sim. Quando as classes perdem coesão, divida-as! 

Portanto, separar uma função grande em muitas pequenas geralmente nos permite dividir 
várias classes também. Isso dá ao nosso programa uma melhor organização e uma estrutura mais 
transparente. 

Como exemplo do que quero dizer. usemos um exemplo respeitado há anos, extraído do 
maravilhoso livro Literate Programming’, de Knuth. A Listagem 10.5 mostra uma tradução em 
Java do programa PrintPrimes de Knuth. Para ser justo com Knuth, este não é o programa que 
ele escreveu, mas o que foi produzido pela sua ferramenta WEB. Uso-o por ser um grande ponto 
de partida para dividir uma função grande em muitas funções e classes menores. 


Listagem 10-5 
PrintPrimes.java 


package literatePrimes; 


public class PrintPrimes ( 
public static d main(String[] args) { 


int P[] - new 
int PAGENUMBER; 
int PAGEOFFSET; 
int ROWOFFSET: 
int C 


3. [Knuih92] 
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Listagem 10-5 (continuação) 
PrintPrimes.java 


| 


int J; 

int K; 

boolean JPRIME; 
int ORD; 

int SQUARE; 


N; 
int MULT(] = new int[ORDMAX + 1]; 


SQUARE - 9; 


while (K « M) ( 
do ( 


J=)+2; 
if (J == SQUARE) ( 
ORD = ORD + 1; 
SQUARE = P[ORD] * P[ORD]; 
MULT(ORD - 1] = J; 
М.= 2; 
JPRIME = true; 
while (N « ORD && JPRIME) ( 
while (MULT(N] « J) 
MULT[N] = MULT[N] + PIN] + PIN]; 
if (MULTIN] J) 
JPRIME = false; 
N=N+1; 


1 
) while (!JPRIME); 
K=K41; 


PAGENUMBER = 1; 
PAGEOFFSET = 1; 
while (PAGEOFFSET <= M) { 
System.out.printlní'The First "+ M + 
* Prime Numbers --- Page " + PAGENUMBER) ; 
System.out.println(""); 
for (ROWOFFSET = PAGEOFFSET; ROWOFFSET < PAGEOFFSET + ER; ROWOFFSET++) [ 
for (C = 0; C « CC;C++) 
if (ROWOFFSET « C * RR «- M) 
System.out.format('&10d*. P[ROWOFFSET + C * RRI); 
System.out.println(*"); 


System.out.printin("\i"); 
PAGENUMBER = PAGENUMBER + 1; 
PAGEOFFSET = PAGEOFFSET + RR * C 
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Este programa, escrito como uma única função, é uma zona; possui uma estrutura com muitas 
endentações, uma abundância de variáveis estranhas e uma estrutura fortemente acoplada. 
No mínimo essa grande função deve ser dividida em algumas menores. 

Da Listagem 10.6 a 10.8 mostra o resultado da divisão do código na Listagem 10.5 em classes 
e funções menores, e seleciona nomes significativos para as classes, funções e variáveis. 


Listagem 10-6 
PrimePrinter.java (refatorado) 


package literatePrimes; 


public class PrimePrinter ( 
public static void main(St 
final NUMBER OF. PRIMES 
int [] primes = PrimeGenerator generate (NUMBER OF. PRIMES) ; 


final int ROWS PER PAGE = 50; 
final int COLUMNS PER PAGE = 4; 
RowColumnPagePrinter tablePrinter = 
new RowColumnPagePrinter (ROWS PER PAGE, 
COLUMNS PER PAGE, 
“The First * + NUMBER OF PRIMES + 
* Prime Numbers"); 


tablePrinter.print primes); 


Listagem 10-7 
RowColumnPagePrinter.java 


package literatePrimes 


import java.10.PrintStream; 
public class RowColumnPagePrinter | 
vate int rowsPerPage; 
private int columnsPerPage; 
numbersPerPage; 
private String pageHeader; 
private PrintStream printStream; 


public RowColumnPagePrinter(int rowsPerPage, 
int columnsPerPage, 
String pageHeader) | 
this.rowsPerPage - rowsPerPage; 
this.columnsPerPage - columnsPerPage; 
this.pageHeader = pagelieade! 
numbersPerPage = rowsPerPage * columnsPerPage; 
printStream = System.out; 
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Listagem 10-7 (continuação) 
RowColumnPagePrinter. java 


public void print(int data[]) f 
int pageNumber - 1; 
for (int firstIndexOnPage - 0; 
firstIndexOnPage « data.length; 
firstindexOnPage += numbersPerPage) { 
int lastIndexOnPage = 
Math.min(firstIndexOnPage + numbersPerPage - 1, 
data.length - 1); 
printPageHeader (pageHeader, pageNumber) : 
printPage(firstIndexOnPage, lastIndexOnPage, data); 
printStream.princln("\f"); 
pageNumber++; 
) 


) 


private void printPage(int firstIndexOnPage, 
int lastIndexOnPage, 
int[] data) ( 
int firstIndexOfLastRowOnPage = 
firstIndexOnPage + rowsPerPage - 1; 
for (int firstIndexInRow = firstIndexOnPage; 
firstIndexInRow <= firstIndexOfLastRowOnPage; 
firstIndexInRow++) ( 
printRow(firstIndexInRow, lastIndexOnPage, data); 
printStream.println(*"); 
} 
} 


private void printRew(int firstIndexInRow, 
int lastIndexOnPage, 
int[] data) í 
for (int column = 0; column < columnsPerPage; colum++) ( 
int index = firstIndexlnRow + column * rowsPerPage; 
if (index «- lastIndexOnPage) 
printStream.format ("$10d", data[index]); 


) 
3 


ring pagekeader, 
int pageNumber) | 
printStream.printin(pageHeader + " --- Page * + pageNumber); 
printStream.printin(*"); 
) 


private void printPageHeader 


public void setOutput(PrintStream printStream) ( 
this.printStream = printStream; 
} 
H 
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Listagem 10-8 
PrimeGenerator. java 


B 


package literatePrimes; 
import java.util.ArrayList; 


public class PrimeGenerator ( 
private static int[] primes; 
private static ArrayList«Integer» multiplesOfPrimeFactors; 


protected static int[] generate(int n) f 
primes = new int(r]; 
muitiplesOfPrimeFactors = new ArrayList<Integer>(); 
set2AsFirstPrimei); 
checkOddNumbersForSubsequent Primes () ; 
return primes: 
| 


private static void set2AsFirstPrime() ( 
primes[0] = 2 
multiples0fPrimeractors.add(2) ; 
} 


private static void checkOddNumbersForSubsequentPrimes(j ( 
2; 


primeIndex < primes. length; 
candidate 2) 
if (isPrime(candidate)) 


private static boolean isPrime(int candidate) { 
if (isLeastRelevantMult ipleOfNextLargerPrimeFactor(candidate)) f 
multiplesOfPrimeFactors add (candidate) ; 
return false; 


return isNotMultipleOfAnyPreviousPrimeFactor candidate); 
+ 


private static boolean 

isLeastRelevantMultiple0fNextLargerPrimeFactor (int candidate) { 
int nextLargerPrimeFactor = primes [multiplesOfPrimeFactors.size()]; 
int leastRelevantMultiple = nextLargerPrimeFactor * nextLargerPrimeFactor; 
return candidate -- leastRelevantMultiple; 


} 


private static boolean 
isNotMult ipleCfAnyPreviousPrimeFactor (int candidate) { 
for iint n п < multiplesOfPrimeFactors.size(); п++) { 
if (isMultipleofNthPrimeractor candidate, n)) 
return false; 
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Listagem 10-8 (continuação) 
PrimeGenerator. java 


return true; 


private static boolean 
isMultipleOfNthPrimeFactor(int candidate, int n) ( 
return 
candidate == smallestOddNthMultipleNotLessThanCandidate (candidate, п}; 


while (multiple « candidate) 
multiple «- 2 * primes[n]; 
multiplesOfPrimeFac „вес (п, multiple!; 
return multiple; 

} 


} 
i} 


A primeira coisa que você deve perceber é que o programa ficou bem maior, indo de uma página 
para quase três. Há diversas razões para esse aumento. Primeiro, o programa refatorado usa 
nomes de variáveis mais longos e descritivos. 

Segundo, ele usa declarações de funções e classes como uma forma de adicionar comentários ao 
código. Terceiro, usamos espaços em branco e técnicas de formatação para manter a legibilidade. 

Note como o programa foi dividido em três responsabilidades principais. O programa 
principal está sozinho na classe PrimePrinter cuja responsabilidade é lidar com o ambiente 
de execução. Ela será modificada se o método de chamada também for. Por exemplo, se esse 
programa fosse convertido para um serviço SOAP, esta seria a classe afetada. 

O RowColumnPagePrinter sabe tudo sobre como formatar uma lista de números em 
páginas com uma certa quantidade de linhas e colunas. Se for preciso modificar a formatação da 
saída, então essa seria a classe afetada. 

A classe PrimeGenerator sabe como gerar uma lista de números primos. Note que ela não 
foi feita para ser instanciada como um objeto. A classe é apenas um escopo prático no qual suas 
variáveis podem ser declaradas e mantidas ocultas. Se o algoritmo para o cálculo de números 
primos mudar, essa classe também irá. 

Não a reescrevemos! Não começamos do zero e criamos um programa novamente. De fato, 
se olhar os dois programas mais de perto, verá que usam o mesmo algoritmo e lógica para 
efetuar as tarefas. 

A alteração foi feita criando-se uma coleção de testes que verificou o comportamento preciso 
do primeiro programa. Então, foram feitas umas pequenas mudanças, uma de cada vez. Após 
cada alteração, executava-se o programa para garantir que o comportamento não havia mudado. 
Um pequeno passo após o outro e o primeiro programa foi limpo e transformado no segundo. 
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Como organizar para alterar 


Para a maioria dos sistemas, a mudança é constante. A cada uma, corremos o risco de o sistema 
não funcionar mais como o esperado. Em um sistema limpo, organizamos nossas classes de 
modo a reduzir os riscos nas alterações. 

A classe Sql na Listagem 10.9 gera strings no formato SQL adequado dado um metadados 
apropriado. É um trabalho continuo e, como tal, ainda não suporta funcionalidade SQL, como as 
instruções update. Quando chegar a hora da classe SQL suportar uma instrução update, teremos 
de “abrir” essa classe e fazer as alterações. Qualquer modificação na classe tem a possibilidade 
de estragar outro código na classe. É preciso testar tudo novamente. 


Listagem 10-9 
classe que precisa ser aberta para alteração 


public class Sal ( 
public Sql iString table, Column[] columns) 
public String create() 
public String insert(Object[] fields) 
public String selectAll\) 
public String findByKey (String keyColumn, String keyvalus) 
public select (Column column, String pattern) 
public String select (Criteria criteria) 
public String preparedInsert () 
private String columnList(Column[] columns) 
private String valuesList(Object[] fields, final Column[] columns] 
private String selectWithCriteria(String criteria) 
private String placeholderListiColumn[] columns) 


A classe Sql deve ser alterada quando adicionamos um novo tipo de instrução ou quando 
mudarmos os detalhes de um único tipo de instrução — por exemplo, se precisarmos modificar 
a funcionalidade do select para suportar “sub-selects”. Esses dois motivos para alteração 
significam que a classe sal viola o SRP. 

Podemos ver essa quebra da regra num simples ponto horizontal. O método realçado da SQL 
mostra que há métodos privados, como o selectWithCriteria, que parecem se relacionar 
apenas às instruções select. 

O comportamento do método privado aplicado apenas a um pequeno subconjunto de 
uma classe por ser uma heurística útil para visualizar possíveis áreas para aperfeiçoamento. 
Entretanto, о indício principal para se tomar uma ação deve ser a alteração do sistema em si. 
Se a classe 591 for considerada logicamente completa, então não temos de nos preocupar em 
separar as responsabilidades. Se não precisamos da funcionalidade update num futuro próximo, 
então devemos deixar a Sal em paz. Mas assim que tivermos de “abrir” uma classe, devemos 
considerar consertar nosso projeto. 

E se considerássemos uma solução como a da Listagem 10.10? Cada método de interface 
pública definido na sal anterior na Listagem 10.9 foi refatorado para sua própria classe 
derivada Sal. Note que os métodos privados, como valuesList, vão diretamente para 
onde são necessários. O comportamento privado comum foi isolado para um par de classes 
utilitárias, Where e ColumnList. 
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Listagem 10-10 


Várias classes fechadas 


abstract public class Sql ( 
public Sql(String table, Column[] columns) 
abstract public String generate(); 

4 


public class CreateSql extends Sql { 
public CreateSqliString table, C. 
êoverride public String generate() 
} 


umn[] columns) 


public class SelectSql extends Sql ( 
public SelectSql (String table, Cclumn[] columns) 
9Override public String generatei) 

) 


public class InsertSql extends Sql ( 
public InsertSql(String table, Column[] columns, Object[] fields} 
aOverride public String generate!) 
private String valuesList (Object [| fields, final Column[] columns) 


public class SelectWithCriceriaSql extends Sql ( 
public SelectWithCriteriasql ( 
String table, Column[] columns, Criteria criteria) 
GOverride public String generate() 


public class SelectWithMatchSql extends Sql ( 
public SelectWithMatchsql( 
String table, Column[] columns, 
@Override public String generate () 
) 


public class FindByKeySql extends Sql 


public FindByKeySgl( 
String table, Column[] columns, String keyColumn, String keyValue) 


&Override public String generate() 


lumn column, String pattern) 


} 


public class PreparedInsertSql extends Sql { 
public PreparedInserrSql (String table, Column[] columns) 
@Override public String generate() ( 
private String placeholderList(Column[] columns) 


) 


public class Where ( 
public Where(String criteria) 
public String generate() 


H 

public class ColumnList ( 
public ColumnList(Column[] columns) 
public String generate() 

) 
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O código em cada classe se torna absurdamente simples. O tempo necessário para entendermos 
qualquer classe caiu para quase nenhum. O risco de que uma função possa prejudicar outra se 
torna ínfima. Do ponto de vista de testes, virou uma tarefa mais fácil testar todos os pontos 
lógicos nesta solução. já que as classes estão isoladas umas das outras. 

Tão importante quanto é quando chega a hora de adicionarmos as instruções update, 
nenhuma das classes existentes precisam ser alteradas! Programamos a lógica para construir 
instruções update numa nova subclasse de sql chamada Updatesal. Nenhum outro código no 
sistema sofrerá com essa mudança. 

Nossa lógica reestruturada da Sal representa o melhor possível. Ela suporta o SRP e outro 
principio-chave de projeto de classe OO, conhecido como Princípio de Aberto-Fechado OCP* 
(sigla em inglês). As classes devem ser abertas para expansão, mas fechadas para alteração. 
Nossa classe $91 reestruturada está aberta para permitir novas funcionalidades através da criação 
de subclasses, mas podemos fazer essa modificação ao mesmo tempo em que mantemos as 
outras classes fechadas. Simplesmente colocamos nossa classe UpdateSal em seu devido lugar. 
Desejamos estruturar nossos sistemas de modo que baguncemos o mínimo possível quando 
os atualizarmos. Num sistema ideal, incorporaríamos novos recursos através da expansão do 
sistema, e não alterando o código existente. 


Como isolar das alteracóes 


As necessidades mudarão, portanto o código também. Aprendemos na introdução à OO que 
há classes concretas. que contêm detalhes de implementação (código), e classes abstratas. que 
representam apenas conceitos. Uma classe do cliente dependente de detalhes concretos corre 
perigo quando tais detalhes são modificados. Podemos oferecer interfaces e classes abstratas 
para ajudar a isolar o impacto desses detalhes. 

Depender de detalhes concretos gera desafios para nosso sistema de teste. Se estivermos 
construindo uma classe Portfolio e ela depender de uma APL TokyoStockExchange externa 
para derivar o valor do portfolio, nossos casos de testes são afetados pela volatilidade dessa 
consulta. É difícil criar um teste quando obtemos uma resposta diferente a cada cinco minutos! 
Em vez de criar a Portfolio de modo que ela dependa diretamente de TokyoStockExchange, 
podemos criar uma interface StockExchange que declare um único método: 

Desenvolvemos TokyostockExchange para implementar essa interface. Também nos 
certificamos se o construtor de Portfolio recebe uma referência a StockExchange como 
parâmetro: 


public Portfolio ( 
private StockExchange exchange; 
public Portfolio(StockExchange exchange) ( 
this.exchange = exchange; 
n 
ji 


) 


Agora nosso teste pode criar uma implementação para testes da interface StockExchange 
que simula a TokyoStockExchange. Essa implementação fixará o valor para qualquer simbolo 
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que testarmos. Se nosso teste demonstrar a compra de cinco ações da Microsoft para nosso 
portfolio, programamos a implementação do teste para sempre retornar U$ 100 dólares por 
ação. Nossa implementação de teste da interface stockExchange se reduz a uma simples 
tabela de consulta. Podemos, então, criar um teste que espere US 500 dólares como o valor 
total do portfolio. 


public class PortfolioTest ( 
private FixedStockExchangestub exchange; 
private Portfolio portfolio; 


@Before 

protected void setUp() throws Exception { 
exchange = new FixedStockExchangeStub(); 
exchange.fix("MSFT”, 100); 
portfolio = new Portfolio(exchange); 

} 


@Test 

public void GivenFiveMSFTTotalShouldBe500() throws Exception { 
portfolio.add(5, “MSFT"); 
Assert.assertEquals(500, portfolio.value()); 


Se o um sistema estiver desacoplado o bastante para ser testado dessa forma, ele também 
será mais flexível e terá maior capacidade de reutilização. A falta de acoplamento significa que 
os elementos de nosso sistema ficam melhores quando isolados uns dos outros e das alterações, 
facilitando o entendimento de cada elemento. 

Ao minimizar o acoplamento dessa forma, nossas classes aderem a outro princípio de projeto de 
classes conhecido como Princípio da Inversão da Independência ,DIP* (sigla em inglês). Basicamente, 
o DIP diz que nossas classes devem depender de abstrações, não de detalhes concretos. 

Em vez de depender da implementação de detalhes da classe TokyoStockExchange, nossa 
classe Portfolio agora é dependente da interface StockExchange, que representa o conceito 
abstrato de pedir o preço atual de um símbolo. Essa isola todos os detalhes específicos da 
obtenção de tal preço, incluindo sua origem. 
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Sistemas 


por Dr. Kevin Dean Wampler 


“Complexidade mata. Ela suga a vida dos desenvolvedores, dificulta o 
planejamento, a construção e o teste dos produtos”. 
—Ray Ozzie, CTO, Microsoft Corporation 
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Como vocé construiria uma cidade? 


Conseguiria tratar de todos os detalhes sozinho? Provavelmente nào. Até mesmo o gerenciamento 
de uma cidade é muito para uma pessoa só. Mesmo assim, as cidades funcionam (na maioria das 
vezes). Isso porque possuem equipes de pessoas que gerenciam partes específicas da cidade, 
o sistema de abastecimento de água, de energia, de tránsito, a segurança pública, as normas 
de construção, e assim por diante. Algumas dessas pessoas são responsáveis pela visão geral, 
enquanto outros se focam nos detalhes. 

As cidades também funcionam porque progrediram em níveis apropriados de e modularidade 
os quais possibilitaram que indivíduos e os “componentes” pudessem trabalhar de forma eficiente, 
mesmo sem ter noção da visão geral. 

Embora equipes de software geralmente sejam organizadas dessa forma também, os sistemas 
nos quais trabalham não costuma ter a mesma divisão de preocupações e níveis de . Um código 
limpo nos ajuda a alcançar esses níveis mais baixos de . Neste capítulo, consideremos como manter 
o código limpo nos níveis de mais altos, o nível do sistema. 


Separe a construção e o uso de um sistema 


Primeiramente, considere que construção é um processo diferente de utilização. Na época em 
que escrevo este livro, há um novo hotel sendo construído que posso ver através da minha janela 
em Chicago. Hoje só há pilares de concreto com uma grua e um elevador preso do lado de 
fora. Todas as pessoas ocupadas lá usavam capacetes de proteção e roupas de trabalho. Em 
mais ou menos um ano, o hotel ficará pronto. A grua e o elevador terão indo embora. O edifício 
estará limpo, envolto em paredes com janelas de vidro e um tingimento atraente. As pessoas que 
trabalharão e ficarão ali também serão diferentes. 


Os sistemas de software devem separar o processo de inicialização — a criação dos objetos 
do aplicativo e a “conexão” entre as dependências — da lógica em tempo de execução que 
vem após a inicialização. 


O processo inicial é uma preocupação da qual qualquer aplicativo deva tratar. E será a primeira 
analisada neste capítulo. A separação de preocupações é uma das técnicas de projeto mais 
antigas e importantes em nossa profissão. 

Infelizmente, a maioria dos aplicativos não faz essa separação. O código do processo 
de inicialização é específico e misturado na lógica em tempo de execução. Abaixo está um 
exemplo típico: 


public Service getService() ( 
if (service == null) 
service = new MyServiceImpl(...); // Padrão bom o suficiente 
para a maioria dos casos? 
return service; 


} 


Essa é a expressão INICIALIZAÇÃO/AVALIAÇÃO TARDIA, digna de vários méritos. Não 
visualizamos a operação geral da construção a menos que realmente usemos o objeto, e, como 
resultado, nosso tempo de inicialização pode ser mais rápido. Também garantimos que nunca 
seja retornado null. 
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Entretanto, agora temos uma dependência codificada permanentemente em MyServiceTmpl 
e tudo o que seu construtor exige (о que omiti). Não podemos compilar sem resolver essas 
dependências, mesmo se nunca usarmos um objeto desse tipo tempo de execução. 

Efetuar testes pode ser um problema. Se MyServiceImpl for um objeto grande, precisamos 
garantir que um TEST DOUBLE! ou MOCK OBJECT seja atribuído à área de operação antes 
deste método ser chamado no teste de unidade. Como temos lógica da construção misturada ao 
processamento normal em tempo de execução, devemos testar todos os caminhos da execução (por 
exemplo, o teste nu11 e seu bloco). Ter essas duas responsabilidades significa que o método faz mais 
de uma coisa, portanto estamos violando, de certa forma, o Princípio da Responsabilidade Unica. 

Talvez o pior de tudo é que nào sabemos se MyServicelmplé 0 objeto correto em todas as 
classes, e foi isso que indiquei no comentário. Por que a classe que possui este método precisa 
enxergar o contexto global? Realmente jamais poderemos saber qual o objeto certo usar aqui? E 
possível que um tipo seja o certo para todos contextos? 

É claro que uma ocorrência de INICIALIZAÇÃO-TARDIA não é um problema sério. 
Entretanto, costuma-se ter muitas instâncias de pequenas expressões como essa nos aplicativos. 
Devido a isso, a estratégia de configuração global (se houver uma) fica espalhada pelo aplicativo, 
com pouca modularidade e. geralmente, duplicação considerável. 

Se formos cuidadosos ao construir sistemas bem estruturados e robustos, jamais devemos 
deixar que expressões convenientes prejudiquem a modularidade. O processo de inicialização 
da construção e atribuição de um objeto não são exceções. Devemos modularizar esse processo 
de separadamente da lógica normal em tempo de execução, e nos certificar que tenhamos uma 
estratégia global e consistente para resolver nossas dependências principais. 


Separação do Main 


Uma maneira de separar a construção do uso é simplesmente colocar todos os aspectos dela no 
main ou em módulos chamados por ele, e modelar o resto do sistema assumindo que todos os 
objetos foram construídos e atribuídos adequadamente (veja a Figura 11.1). 

É fácil acompanhar o fluxo de controle. A função main constrói os objetos necessários para 
0 sistema e, então, os passa ao aplicativo, que simplesmente os usa. Note a direção das setas de 
dependência cruzando a barreira entre o main e o aplicativo. 

Todas apontam para a mesma direção, para longe do main. Isso significa que o 
aplicativo não enxerga о main ou o processo de construção, mas apenas espera que tudo 
seja devidamente construído. 


Factories 


É claro que de vez em quando precisamos passar o controle para o aplicativo quando um 
objeto for criado. Por exemplo, em um sistema de processamento de pedidos, o aplicativo 
deve criar instâncias do LineTtem e adicionar a um Order. Neste caso, podemos usar o 
padrão ABSTRACT FACTORY: para passar o controle ao aplicativo quando for preciso criar 
os objetos LineItem, mas mantenha os detalhes dessa construção separada do código do 
aplicativo (veja a Figura 11.2). 


1 TMezzaros07]. 
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oc: Objeto 
Construído 


<<interface>> 
LineltemFactory 


+ makeLineltem 


Figura 11.2: Separação da construção com uma factory 


Novamente, observe que todas as dependências apontam de main para o aplicativo 
OrderProcessing. Isso significa que ele está desacoplado dos detalhes de como criar um 
LineItem. Essa capacidade é mantida em LineItemFactory Implementation, que está no 
mesmo lado da linha que o main. E mesmo assim o aplicativo possui controle total quando na 
criação de instâncias de LineTtem e pode até oferecer parâmetros do construtor específicos 
ao aplicativo. 


Injeção de dependência 
Um mecanismo poderoso para separar a construção do uso é a Injeção de Dependência (DI, 


sigla em inglês), a aplicação da Inversão de Controle (IoC, sigla em inglês ao gerenciamento de 
dependência”. A IoC move as responsabilidades secundárias de um objeto para outros dedicados 


3. Ma, Falaj pot exemple! 
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ao propósito que se deseja, dessa forma suportando o Princípio da Responsabilidade Única. 
Em vez disso, ela deve passar essa responsabilidade para outro mecanismo “dominante”, com 
isso invertendo o controle. Como essa configuração é uma preocupação global, esse mecanismo 
dominante geralmente será ou a rotina “principal” ou um contéiner de tarefa específica. 

As consultas ao JNDI são implementações “parciais” da DI, na qual um objeto pede a um 
servidor de diretórios um “serviço” com um nome específico. 


MyService myService = (MyService)(jndiContext.lockup(*NameOfMyService")); 


O objeto chamador não controla qual tipo será realmente retornado (contanto que ele 
implemente a interface apropriada, é claro), mas ele ainda determina ativamente a dependência. 

A Injeção de Dependência Verdadeira vai mais além. A classe não determina diretamente 
suas dependências; ela fica completamente passiva e oferece métodos de escrita (setters) ou 
parâmetros de construtores (ou ambos) que serão usados para injetar as dependências. Durante 
o processo de construção, o contêiner de DI instancia os objetos necessários (geralmente sob 
demanda) e usa os parâmetros do construtor ou os métodos de escrita fornecidos para conectar 
as dependências. 

Quais objetos dependentes são usados realmente são especificados por um arquivo de 
configuração ou diretamente programando-se no módulo de construção de tarefa específica. 

O framework Spring oferece o melhor e mais conhecido contéiner de DI para Java*. Você 
define quais objetos conectar um ao outro em um arquivo de configuração, e depois solicita 
objetos especificos pelo nome no código Java. Logo veremos um exemplo. 

Mas e sobre as virtudes da INICIALIZACAO-TARDIA? Essa expressão, de vez em 
quando, ainda é útil com a DI. Primeiro, a maioria dos contêineres de DI não criará objetos 
até que sejam necessários. Segundo, muitos desses contêineres oferecem mecanismos para 
invocar factories ou construir proxies, que poderiam ser usados para sanar a AVALIAÇÃO- 
TARDIA e otimizações* semelhantes, 


Desenvolvimento gradual 


Vilarejos viram pequenas cidades, que viram cidades grandes. No início as ruas são estreitas е 
quase não existem e, com tempo, elas são pavimentadas e, então, alargadas. Pequenos edifícios 
e terrenos vazios são substituídos por edificações maiores, algumas das quais acabarão virando 
arranha-céus. 

No começo, não há serviços, como abastecimento de energia, água, esgoto e Internet (opa!). 
E só serão adicionados quando aumentar a densidade da população e de edificações. 

Mas esse desenvolvimento não está livre de problemas. Quantas vezes, devido a um projeto 
de “melhoria” das avenidas você dirigiu por engarrafamentos e se perguntou “Por que não 
construíram as ruas largas o bastante desde o início?". 

Mas não podia ter sido de outra forma. Como justificar o custo de construção de uma 
via expressa de seis faixas passando no meio de uma cidade pequena já antecipando seu 
desenvolvimento? Quem desejaria tal avenida passando por sua cidade? 

É mito dizer que podemos conseguir um sistema “correto de primeira”. Em vez disso, devemos 
implementar apenas os fatos de hoje e, então, refatorar e expandir o sistema, implementando novos 


Bon дасына ы RO 
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fatos amanhã. Essa é a essência das agilidades iterativa e incremental. O desenvolvimento dirigido a 
testes, a refatoração e o código limpo que produzem fazem com que isso tudo funcione em nível de 
código. Mas e em nível de sistema? A estrutura do sistema não requer um pré-planejamento? Claro 
que sim, ele não pode crescer gradualmente do simples para o complexo, pode? 


Se comparados aos sistemas fisicos, os de software são únicos, e suas arquiteturas podem 

crescer gradualmente se mantivermos uma separação devida de preocupações. 

Como veremos, é a natureza efêmera dos sistemas de software que possibilitam isso. 
Consideremos primeiro um contra-exemplo de uma arquitetura que não separa as preocupações 
de forma adequada. 

As arquiteturas ЕЈВІ e EJB2 originais são um bom exemplo e, devido a isso, geram obstáculos 
desnecessários para o crescimento orgânico. Considere uma Entity Bean para uma classe Bank 
frequente. Uma entity bean é uma representação, na memória, dos dados relacionais, ou seja, a 
linha de uma tabela. 

Primeiro. você define uma interface local (no processo) ou remota (separada da JVM), que os 
clientes usariam. A Listagem 11.1 mostra uma possível interface local: 


Listagem 11-1 
Interface EJB2 local para um EJB da cl 


package com.example.banking; 
import 
import à 


public interface BankLocal extends java.ejb.EJBLocalObject { 
String getStreetAddrl() throws EJBExcepti 
String gecStreerAddr2(! throws EJBExceprio! 
5 y EJBException; 
tate() throws EJBException; 
de() tnrows EJBException; 
tStreetAddrl(String streetl! throws EJBException; 
void setStreetAddr2 (String street2) throws EJBException; 
void setCity(S city) throws EJBException; 
void setState(String state) throws EJBException; 


void setZipCode (String zip) throws EJBException; 
Collection getaccounts() throws EJBExcepticn; 

void setAccounts(Collection accounts) throws EJBException; 
void addAccount(AccountDTO accountDTO) throws EJBException; 


Exibi diversos atributos para o endereco do Bank e uma colecào de contas (account) que há 
no banco (bank), cada uma com seus dados manipulados por um EJB de Account separado. A 
Listagem 11.2 mostra a classe de implementação correspondente para o bean de Bank. 
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Listagem 11-2 

Implementação da Entity Bean do EJB2 correspondente 
package com.example.banking; 

import java.util.Collections; 

import javax.ejb.*; 


public abstract class Bank implements javax.ejb.EntityBean { 
/ Business logic... 
public abstract String getStreetAddrli); 
public abstract String getStreetAddr2 (1; 
abstract String getCity(); 
public abstract String getState!]; 
public abstract String getZipCode() ; 
public abstract void setStreetAddr1 (String streetl} 
public abstract void setStreetAddr2(String street 2 
public abstract void setCicy (String city]; 
public abstract void setState(String state); 
public abstract void setZipCode(String 21р); 
public abstract Collection getAccounts(); 
abstract void setAccountsiCollection accounts); 
public void addAccount (AccountDTO accountDTO) ( 
InitialContext cont ialContexti); 
AccountHomeLocal accountHome = context. lookup("AccountHomeLocal") ; 
AccountLocal account = accountHome.create (account DTO) ; 
Collection accounts = getAcccunts(); 
accounts. add (account) ; 


abstract void secId(Integer id); 
abstract Integer getldl 
Integer ejbCreate(Integer id) ( ... ] 
void ejbPostCreate(Integer id) ( ... ) 

rest had to be implemented but were usually empty: 
public void setEnt ntext(EntityContext ctx) () 
public void unsetEntityContext () 
public void ejbactivate() () 
public void ejbPassivate() () 
public void ejbLoad() {} 
Public void ejbStore() (] 
public void ejbRemove() () 


1 


Não mostrei a interface LocalHome correspondente — basicamente uma factory usada рага 
criar objetos — e nem um dos possíveis métodos de localização (consulta, ou queries) que 
você pode adicionar. Por fim, você teve de criar um ou mais descritores de implementação 
que especifiquem os detalhes do mapeamento de objetos relacionais para um armazenamento 
permanente de dados, para a ação de transação desejada, para os limites de segurança, etc. 

A lógica de negócio está fortemente acoplada ao “container” do aplicativo EJB2. Você 
precisa criar subclasses dos tipos do container e fornecer muitos métodos do tipo lifecycle 
exigidos pelo container. 

Esse acoplamento ao container pesado dificulta o teste de unidade isolado. 

É necessário fazer uma simulação do container, o que é difícil, ou gastar muito tempo 
implementando EJBs e testes em um servidor real. Reutilizar externamente e de modo eficiente 
a arquitetura EJB2 é impossível devido ao forte acoplamento. 
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Por fim, mesmo a programação orientada a objeto foi prejudicada. Um bean não pode herdar 
de outro. Note a lógica para adicionar uma nova conta. É comum nos beans do EJB2 definir 
os “objetos de transferência de dados” (DTOs, sigla em inglés) que são basicamente “structs” 
(estruturas) sem atividade alguma. 

Isso costuma levar a tipos redundantes que possuem praticamente os mesmos dados, e requer 
códigos padronizados para copiar dados de um objeto para outro. 


Preocupações transversais 


A arquitetura EJB2 chega perto de uma divisão real de preocupações em algumas áreas. Por 
exemplo, a segurança, a comunicação desejada e alguns dos comportamentos de persistência são 
declarados dos descritores de implementação, independentemente do código-fonte. 

Note que preocupações como persistência tendem a atravessar os limites naturais dos objetos 
de um domínio. Você deseja manter todos os seus objetos através da mesma estratégia. por 
exemplo, usando um SGBD* versus bancos de dados nào-relacionais, seguindo certas convenções 
de nomenclatura para tabelas e colunas, usando semânticas transacionais consistentes, etc. 

Em princípio, você pode pensar em sua estratégia de persistência de uma forma modular 
e encapsulada. Mesmo assim, na prática, é preciso basicamente espalhar por vários objetos 
o mesmo código que implementa tal estratégia. Usamos o termo preocupações transversais 
para preocupações como essa. Novamente, o framework de persistência e a lógica de domínio 
(isolada) podem ser modulares. O problema é a minuciosa interseção desses domínios. 

De fato, o modo como a arquitetura EJB trata da persistência, da segurança e das transações 
“antecipa” a Programação Orientada a Aspecto (POAY — uma abordagem de propósito geral 
para restaurar a modularidade para preocupações transversais. 

Na POA, construções modulares chamadas aspectos especificam quais pontos no sistema 
devem ter seus comportamentos alterados de uma forma consistente para suportar uma 
determinada preocupação. Essa especificação é feita através de um mecanismo sucinto declarativo 
ou programático. 

Usando a persistência como exemplo, você declararia quais objetos e atributos (ou padrões 
do tipo) devem ser mantidos е, então, delegar as tarefas de persistência ao seu framework de 
persistência. О framework da POA efetua as alterações de comportamento de modo não-invasivo* 
no código a ser alterado. Vejamos três aspectos ou mecanismos voltados a aspectos em Java. 


Proxies para Java 


Os proxies para Java são adequados para situações simples, como empacotar chamadas de 
métodos em objetos ou classes individuais. Entretanto, os proxies dinâmicos oferecidos no JDK 
só funcionam com interfaces. Para usar proxies em classe, é preciso usar uma biblioteca de 
manipulação de Bytecode, como CGLIB, ASM ou Javassist”. 

A Listagem 11.3 mostra o esqueleto para um Proxy do JDK que ofereça suporte à persistência 
para nosso aplicativo Bank, cobrindo apenas os métodos para obter e alterar a lista de contas. 


Proxies para Java 
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Listagem 11-3 
Exemplo de proxy do JDK 


i| Bank. java (suppressing package names 
import java.utils.*; 


11 The abstraction of a bank. 
public interface Bank ( 
Collection<Account> getAccounts |) ; 
void setAccounts (Collection<Account> accounts); 


{/ BankImpl.java 
rc java.utils.*; 


i| The “Plain Old Java Object” (POJO) implementing the abstraction. 
public class BankImpl implements Bank ( 
private List«Account» accounts; 


public Collection<Account> getAccounts() ( 
return accounts; 
1 


public void setAccounts (Collection<Account> accounts) { 
this.accounts = new ArrayList«Account»(); 
for (Account account: accounts) { 
this.accounts.add (account) ; 
} 
} 


) 


4) BankProxyHandler.java 
import java.lang.reflect.*; 
import java.util.*; 


d 


11 “InvocationHandler* required by the proxy API. 
public class BankProxyHandler implements InvocationHandler ( 
private Bank bank; 


public BankHandler (Bank bank) { 
this.bank - bank; 
) 


// Method defined in InvocationHandler 
public Object invoke(Object proxy, Method method, Object[] args) 
throws Throwable ( 

String methodName = method.getName!); 

if (methodName.equals("getAccounts")) { 
bank. setAccount s (getAccountsFromDatabase ()) ; 
return bank.getAccounts(); 
else if (methodName.equals("setAccounts"}) { 
bank. setAccounts((Collection<Account>) args[0]); 
setAccountsToDatabase (bank. getAccounts()) ; 
return null; 
else { 
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Listagem 11-3 (continuacáo) 
Exemplo de proxy do JDK 


/ Lots of details her 
protected Collection<Account> getAccou 
protected void setAccountsToDatabase (Ci 


romDatabase() ( ... } 
ection<Account> 


/ Somewhere else... 


Bank bank = (Bank) Proxy .newProxyInstance( 
Bank.class.getClassLoader(), 
new Class[] { Bank.class ), 
new BankProxyHandler (new Bank: 


910); 


Definimos uma interface Bank, que será empacotada pelo proxy, e um Objeto Java Antigo e 
Simples (POJO, sigla em inglês), chamado BankImp1, que implementa a lógica de negócio. 
(Falaremos depois sobre POJOs). 

A API do Proxy requer um objeto InvocationHandler ao qual ela chama para implementar 
quaisquer chamadas ao método Bank feita pelo proxy. Nosso BankProxyHandler usa a API 
de Reflexão do Java para mapear as chamadas aos métodos genéricos correspondentes em 
BankImp1, e assim por diante. 

Há bastante código aqui que é relativamente complicado, mesmo para esse caso simples". 

Usar uma das bibliotecas de manipulação de bytes é igualmente desafiador. Este “volume” de 
código e sua complexidade são duas das desvantagens de usar proxies. Eles dificultam a criação de 
um código limpo! Ademais, os proxies não oferecem um mecanismo para a especificação de certas 
“partes” para execução através de todo o sistema — necessário para uma solução de POA real". 


Frameworks de POA puramente Java 


Felizmente, há ferramentas que podem tratar automaticamente da maioria dos proxies padronizados. 
Estes são usados internamente em diversos frameworks como, por exemplo, POA com Spring e 
com JBoss, para implementar aspectos puramente em Java". No Spring, você escreve sua lógica 
de negócio como Objeto Java Antigo e Simples. Os POJOs estão simplesmente centrados em 
seus domínios. Eles não possuem dependências nas estruturas empresariais (ou qualquer outro 
domínio). Dessa forma, em tese, eles são mais simples e fáceis de testar. A simplicidade relativa 
facilita a garantia de que você esteja implementado as user stories correspondentes de modo 
correto e a manutenção e o desenvolvimento do código em user stories futuras. 

Você incorpora a estrutura necessária do aplicativo, incluindo as preocupações transversais, 
como persistência, transações, segurança, fazer cache, transferência automática por falha 
(failover), etc., usando arquivos de configuração com declarações ou APIs. Em muitos casos, 
você realmente especifica os aspectos da biblioteca do Spring ou do JBoss, onde o framework 
trata dos mecanismos do uso dos proxies em Java ou de bibliotecas de Bytecode transparentes 
ao usuário. Essas declarações controlam o contêiner de injeção de dependência, que instancia os 
objetos principais e os conecta sob demanda. 

A Listagem 11.4 mostra um fragmento típico de um arquivo de configuração do Spring V2.5, 
o app.xml": 


10. Para exemplos mais detalhados do АРІ do Proxy e de seu uso. consulte, por exemplo. [Goetz]. 
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Listagem 11-4 
Arquivo de configuração do Spring 2.X 


beans> 


«bean id="appDataScurce* 
class="org. apache. commons. dbcp.BasicDataSource* 
destroy-method="close" 
p:driverClassNam 


mysql. jdbc.Driver* 
host :3306/mydb* 


.example.banking.persistence.BankDataAccessObject" 
p:dataScurce-ret-'appDataScurce' /> 


«bean id="bank" 


class-'com.example.banking.model.Pank* 


pidataAccessQbiect-ref-"bankDataAccessObject " /» 


</beans> 


Cada “bean” é como uma parte de uma “Boneca Russa”, com um objeto domain para um Bank 
configurado com um proxy (empacotado) por um objeto de acesso a dados (DAO, sigla em inglês), 
que foi configurado com um proxy pela fonte de dados do driver JDBC. (Veja a Figura 11.3). 


Figura 11-3 
A “Boneca Russa" do decorators 


O cliente acha que está chamando getaccounts() em um objeto Bank, mas na verdade 
está se comunicando com a parte mais externa de um conjunto de objetos DECORATOR" 
aninhados que estendem o comportamento básico do POJO Bank. Poderíamos adicionar outros 
DECORATOR para transações, efetuação de cache, etc. 

No aplicativo. são necessárias algumas linhas para solicitar o contêiner da DI para os objetos 
no nível mais superior do sistema, como especificado no arquivo XML. 


XmlBeanFactory bf = 
new XmlBeanFactory(new ClassPathResource(“app.xml”, getClass())); 
Bank bank = (Bank) bf.getBean("bank"); 


Devido à necessidade de tão poucas linhas do código Java específico para o Spring, o aplicativo 
está quase completamente desacoplado do Spring, eliminando todos os problemas de acoplamento 
de sistemas como o EJB2. 


14. IGOFL 
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Embora o XML possa ser detalhado e difícil de ler“, a “política” especificada nesses arquivos 
de configuração é mais simples do que o proxy complicado e a lógica do aspecto que fica oculta 
e é criada automaticamente. Esse tipo de arquitetura é tão urgente que levou frameworks como 
o Spring a efetuarem uma reformulação completa do padrão EJB para a versão 3. O EJB3 
majoritariamente segue o modelo do Spring de suporte a declarações a preocupações transversais 
usando os arquivos de configuração XML e/ou as anotações do Java 5. 

A Listagem 11.5 mostra o EJB3'* com nosso objeto Bank reescrito. 


Listagem 11-5 
Um EJB do Bank no EBJ3 


package com.example.banking.model ; 
import j 


import Java.util.Collection 


SEntity 

STableíname = *BANKS") 

public class Bank slements java.io.Serializable { 
8Id &GeneratedValue(strategy-GeneraticnType.AUTO) 


private int id; 


@Embeddable // An object “inlined” in Bank's DB row 
public class Address ( 

protected String streetAddrl; 

protected String streetAddr2; 

Protected String city; 

protected String state; 

protected String zipCode; 


SEmbedded 
ate address address; 


üOneToMany (cascade 
mappedEy: 
private Collection 


ascadeType.ALL, fetch = FetchType.EAGER, 


accounts = new Arraylist«Account»(); 


public int getld() ( 
return id; 


void setId(int id) ( 
s.id = id; 


public void addAccount (Account account) ( 
account.setBank(this); 
accounts .add (account); 


public Collecrion«Account» getAccounts() { 
return accoun 
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Listagem 11-5 (continuação) 
Um EJB do Bank no EBJ3 


public void setAccounts (Collection<Account> accounts) { 
this.accounts = accounts; 


) 


O código está muito mais limpo do que o do EJB2 original. Alguns dos detalhes da entidade 
ainda estão lá, contidos nas anotações. Entretanto, como nenhuma daquelas informações está fora 
das anotações, o código fica limpo, claro e, portanto, fácil de testar, fazer a manutenção, etc. 

Se desejar, você pode mover algumas ou todas as informações nas anotações sobre a 
persistência para os descritores de implementação XML, deixando um POJO puro. Se os detalhes 
de mapeamento da persistência não mudarem frequentemente, muitas equipes podem optar por 
manter as anotações, entretanto com muito menos efeitos prejudiciais se comparado ao modo 
invasivo do EJB2. 


Aspectos do AspectJ 


Finalmente, a ferramenta mais famosa para a separação de preocupações através de aspectos 
é a linguagem AspectJ”, uma extensão do Java que oferece suporte de “primeira-classe” a 
aspectos como construtores de modularidade. A abordagem puramente Java oferecida pela POA 
em Spring e em JBoss são o suficiente para 80-90% dos casos nos quais os aspectos são mais 
úteis. Entretanto, o AspectJ proporciona uma série de ferramentas rica e poderosa para separar 
preocupações. Sua desvantagem é ter de usar várias ferramentas novas e aprender a estrutura ¢ 0 
uso das expressões de uma nova linguagem. 

Uma “forma de anotação” do Aspect] recentemente lançada, na qual usam-se anotações 
do Java 5 para definir aspectos usando um código puramente Java, Ameniza parcialmente essa 
questão do uso de novas ferramentas. Ademais, o Framework do Spring possui uma série de 
recursos que facilita ainda mais, para uma equipe com experiência limitada em AspectJ, a 
inclusão de aspectos baseados em anotações. 

Uma discussão completa sobre o AspectJ foge do escopo deste livro. Para isso, consulte 


[AspectJ], [Colyer] e [Spring]. 


Testes na arquitetura do sistema 


A capacidade de separar preocupações através de abordagens voltadas a aspectos não pode ser 
exagerada. Se puder escrever a lógica de domínio de seu aplicativo usando POJOs, desacoplados 
de qualquer preocupações acerca da arquitetura em nível de código, então é possível testar 
sua arquitetura. Você pode desenvolvê-la do simples ao sofisticado. se for preciso, através da 
adoção de novas tecnologias sob demanda. Não é necessário fazer um BDUF (Big Design Up 
Front). De fato, um BDUF é até mesmo prejudicial por inibir a adaptação a mudanças devido à 
resistência psicológica de descartar os esforços anteriores e devido à forma pela qual a escolha 
da arquitetura influencia as ideias seguintes sobre o design. 

Arquitetos de construções têm de fazer um BDUF porque não é prático fazer alterações 
radicais na arquitetura para uma estrutura fisica grande após o início da construção”. 


ПЕНА rn qai o eae 
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Embora o software tenha sua própria mecânica”, é economicamente prático fazer alterações 
radicais se a estrutura separa de forma eficiente suas preocupações. 

Isso significa que podemos iniciar um projeto de Software com uma arquitetura simples, 
porém bem desacoplada. fornecendo rapidamente user stories que funcionem e, então, 
adicionando mais infra-estrutura conforme o desenvolvemos, Alguns dos maiores sites da Web 
alcançaram um grau de disponibilidade e performance muito altos através do uso de cache 
sofisticado de dados, segurança, virtualização, e assim por diante, tudo feito de forma eficiente 
e flexível porque os projetos com acoplamento mínimo são apropriadamente simples em cada 
nível de e de escopo. 

E claro que isso não quer dizer que iniciamos um projeto sem algum planejamento. Temos 
certas expectativas a respeito do escopo, objetivos e programação gerais para o projeto, assim 
como para a estrutura geral do sistema final. Todavia, devemos manter a capacidade de alterações 
durante o desenvolvimento no caso de aperfeiçoamentos. 

A arquitetura anterior EJB é uma das muitas APIs bem conhecidas que foram desenvolvidas 
de modo exagerado e que comprometeram a separação de preocupações. Mesmo tais APIs podem 
ser destrutivas se realmente não forem necessárias. Uma boa API deve ficar oculta na maioria 
das vezes, portanto a equipe expande a maioria de seus esforços criativos centralizados nas 
user stories sendo implementadas. Caso contrário, os limites da arquitetura inibirão a entrega 
eficiente do melhor serviço ao consumidor. 

Para recapitular: 


Uma arquitetura de sistema adequada consiste em domínios modularizados de 
preocupações, cada um implementado com POJOs — Objetos Java Antigos e Simples, ou 
outros. Os diferentes dominios são integrados uns aos outros com ferramentas de Aspectos 
ou voltadas para eles pouco invasivas. Pode-se testar essa arquitetura da mesma forma 
que se faz com o código. 


Otimize a tomada de decisões 


Modularidade e separação de preocupações descentralizam o gerenciamento e possibilitam a 
tomada de decisões. Em um sistema consideravelmente grande, seja uma cidade ou um projeto 
de software, ninguém pode tomar todas as decisões. 

Todos sabemos que o melhor é designar responsabilidades às pessoas mais qualificadas. 
Geralmente nos esquecemos que também é melhor adiar as decisões até o último momento. 
Isso não é ser preguiçoso ou irresponsável, mas permitir-nos tomar decisões quando tivermos as 
melhores informações possíveis. 

Uma decisão prematura é tomada sem muitas informações adequadas. Teremos muito 
menos retorno do consumidor, reflexão sobre o projeto e experiência com nossas escolhas de 
implementação se decidirmos muito cedo. 


A agilidade oferecida por um sistema POJO com preocupações modularizadas nos permite 
uma otimização — decisões na hora certa — baseando-se nas informações mais recentes. Além 
de também reduzir complexidade dessas decisões. 


20. O termo mecânica de software foi usado primeiramente por [Kolencc]. 
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Use padrões sabiamente quando eles adicionarem um 
valor demonstrativo 


É uma coisa maravilhosa assistir à construção de uma infra-estrutura devido ao ritmo com que 
as novas estruturas são construídas (mesmo num inverno rigoroso) e aos projetos extraordinários 
possíveis com a tecnologia atual. Uma construção é um mercado maduro com partes altamente 
otimizadas, métodos e padrões que evoluíram sob pressão por séculos. 

Muitas equipes usavam a arquitetura EJB2 porque ela era padrão, mesmo com o advento de 
planejamentos mais diretos e leves. Já vi equipes ficarem obcecadas com diversos padrões muito 
populares e perderem o foco no quesito de implementação voltado para seus consumidores. 


Os padrões facilitam a reutilização de ideias e componentes, recrutam pessoas com 
experiência considerável, encapsulam boas ideias e conectam os componentes. Entretanto, 
o processo de criação de padrões pode, às vezes, ser muito longo para que o mercado 
“fique à espera deles, e alguns padrões acabam se desviando das necessidades reais das 
pessoas a quem eles pretendem servir. 


Sistemas precisam de linguagens específicas 
a um domínio 


A construção de infra-estruturas, assim como a maioria dos domínios. desenvolveu uma linguagem 
rica com vocabulário, expressões e padrões”! que expressam informações essenciais de maneira 
clara e concisa. Houve recentemente na área de softwares uma retomada do interesse pela criação 
de Linguagens Especificas a um Dominio (DSLs, sigla em inglês)”, que são linguagens separadas, 
pequenos scripts ou APIs em linguagens padrão que permitem a escrita do código num formato que 
possa ser lido como uma prosa redigida por um especialista em domínio. 

Uma boa DSL minimiza a “distância de comunicação” entre o conceito de um domínio e o 
código que o implementa, assim como as práticas flexíveis otimizam a comunicação entre os 
membros de uma equipe e a desta com suas partes interessadas. Se estiver implementando a 
lógica de um domínio na mesma linguagem usada pelo especialista em domínios, haverá menos 
risco de erro na tradução do domínio para a implementação. 

As Linguagens Específicas a um Domínio permitem todos os níveis de e todos os domínios 
no aplicativo a ser expresso como POJOs, desde um nível mais alto até os detalhes de baixo 
nível. 


Conclusão 


Os sistemas também devem ser limpos. Uma arquitetura invasiva afeta a agilidade e sobrepuja 
a lógica do domínio que, quando ofuscada, perde-se qualidade porque os bugs se escondem 
mais facilmente e dificulta a implementação. Se a agilidade for comprometida, a produtividade 
também será e se perderão as vantagens do TDD. EM todos os níveis de , o objetivo deve 
estar claro. Isso só acontecerá se você criar POJOs e usar mecanismos voltados a aspectos para 
incorporar de modo não invasivo outras preocupações de implementação. 
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Esteja vocé desenvolvendo sistemas ou módulos individuais, jamais se esqueca de usar a coisa 
mais simples que funcione. 
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Emergência 


por Jeff Langr 


Obtendo clareza através de um processo de emergência 


E se houvesse quatro regras simples que você pudesse usar para lhe ajudar na criação de bons 
projetos enquanto trabalhasse? E se ao seguir essas regras você obtivesse conhecimentos sobre a 
estrutura e o modelo de seu código, facilitando a aplicação de princípios, como o SRP e o DIP? 
E se essas quatro regras facilitassem a emergência de bons projetos? Muitos de nós achamos que 
as quatro regras do Projeto Simples! de Kent Beck sejam de ajuda considerável na criação de um 
software bem projetado. 


L [XPE]. 
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De acordo com Kent, um projeto é “simples” se seguir as seguintes regras: 


* Efetuar todos os testes; 

* Sem duplicação de código; 

* Expressar o propósito do programador 

* Minimizar o nümero de classes e métodos 


Essas regras estão em ordem de relevância. 


Regra 1 de Projeto Simples: Efetue todos os testes 


Primeiro e acima de tudo, um projeto deve gerar um sistema que funcione como o esperado. Um 
sistema pode ter um projeto perfeito no papel, mas se não há uma maneira simples de verificar se 
ele realmente funciona como o planejado, então o que está escrito é dubitável. 

Um sistema que é testado detalhadamente e que passa em todos os testes é um sistema passível 
de testes. Isso pode parecer óbvio, mas é importante. Os sistemas que não podem ser testados não 
podem ser verificados. Logo, pode-ser dizer que um sistema que não pode ser verificado, jamais 
deveria ser implementado. 

Felizmente, tornar nossos sistemas passíveis de teste nos direciona a um projeto no qual 
nossas classes sejam pequenas e de propósito único. Simplesmente é mais fácil testar classes que 
sigam o SRP. Quanto mais testes criarmos, mais seremos direcionados a coisas mais simples de 
serem testadas. Portanto, garantir que nosso sistema seja completamente passível de teste nos 
ajuda a cria projetos melhores. 

O acoplamento forte dificulta a criação de testes. Portanto, similarmente, quanto mais testes 
criarmos, usaremos mais princípios como o DIP e ferramentas como a injeção de dependência. 
interfaces e de modo a minimizar о acoplamento. Assim, nossos projetos se tornam ainda 
melhores. 

O interessante é que ao seguir uma regra simples e óbvia a qual afirma que precisamos ter 
testes e executá-los, afeta constantemente a integração de nosso sistema aos objetivos principais 
da OO de acoplamento fraco e coesão alta. Criar testes leva a projetos melhores. 


Regras de 2 a 4 de Projeto Simples: Refatoração 


Agora que temos testes, podemos manter nosso código e nossas classes limpas. Para isso, 
refatoramos gradualmente o código. Para cada linha nova que adicionarmos, paramos e refletimos 
sobre o novo projeto. Acabamos de prejudicá-lo? Caso positivo, nós o limpamos e rodamos 
nossos restes para nos certificar de que não danificamos nada. O fato de termos esses testes 
elimina o receio de que. ao limparmos o código, podemos danificá-lo. 

Durante a fase de refatoração, podemos aplicar qualquer conceito sobre um bom projeto 
de software. Podemos aumentar a coesão, diminuir o acoplamento, separar preocupações. 
modularizar as preocupações do sistema, reduzir nossas classes e funções, escolher nomes 
melhores, e por aí vai. Ademais, também podemos aplicar as três regras finais do projeto simples: 
eliminar a duplicação, garantir a expressividade e minimizar o número de classes e métodos. 
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Sem repetição de código 


A repetição de código é o inimigo principal para um sistema bem desenvolvido. Ela representa 
trabalho, risco e complexidade desnecessária extras. A duplicação se apresenta de várias formas. 
Linhas de código que parecem idênticas são, é claro, duplicações. 

Linhas de código semelhantes geralmente podem ser modificadas de modo que fiquem mais 
parecidas ainda para serem refatoradas mais facilmente, Há outros tipos de duplicação também, 
como a de implementação. Por exemplo, podemos ter dois métodos na classe de uma coleção: 


int size() O 
boolean isEmpty() () 


Poderíamos ter implementações separadas para cada método. O isEmpty poderia usar um 
booleano, enquanto size poderia usar um contador. Ou poderíamos eliminar essa duplicação 
colocando isEmpty na declaração de size: 


boolean isEmpty() ( 
return 0 == size(); 


} 


Criar um sistema limpo requer a eliminação de código repetido, mesmo que sejam algumas 
linhas. Por exemplo, considere o código abaixo: 


public void scaleToOneDimension( 
float desiredDimension, float imageDimension) 
i 
if (Math.abs(desiredDimension - imageDimension) < 


errorThreshold) 
return; 
float scalingFactor = desiredDimension / imageDimension; 
scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01£); 


RenderedOp newImage = ImageUtilities.getScaledImage( 
image, scalingFactor, scalingFactor); 
image.dispose(); 
System.gc(); 
image = newImage; 

H 


public synchronized void rotate(int degrees) ( 
RenderedOp newImage - ImageUtilities.getRotatedImage( 
image, degrees); 
image.dispose(); 
System.gc(); 
image = newImage; 

H 


A fim de manter esse código limpo, devemos eliminar a pequena quantidade de duplicação 
entre os métodos scaleToOneDimension e rotate: 


public void scaleToOneDimension( 
float desiredDimension, float imageDimension) 
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é 
if (Math.abs (desiredDimension - imageDimension) < 
errorThreshold) 


return; 
float scalingFactor = desiredDimension / imageDimension; 
scalingFactor = (float) (Math.floor(scalingFactor * 100) * 0.01f); 


replacelImage(ImageUtilities.getScaledImage( 
image, scalingFactor, scalingFactor)); 
) 


public synchronized void rotate(int degrees) { 
replaceImage (ImageUtilities.getRotatedImage (image, degr: 


} 


private void replaceImage(RenderedOp newImage) ( 


Ao extrairmos a semelhança neste nível baixissimo, começamos a notar as violações ao SRP. 

Dessa forma, podemos mover um método recém-extraído para outra classe, o que aumentaria 
sua visibilidade. Outra pessoa na equipe talvez perceba a oportunidade para abstrair mais a frente 
o novo método e usá-lo em um contexto diferente. Essa “pequena reutilização” pode reduzir 
consideravelmente a complexidade do sistema. Entender como reutilizar uma pequena parte do 
código é fundamental para fazer uso da utilização num escopo maior. 

O padrão TEMPLATE METHOD? é uma técnica comum para a remoção de duplicação em 
alto nível. Por exemplo: 


public class VacationPolicy ( 
public void accrueUSDivisionVacation() ( 

// codigo para calcular as ferias baseando-se nas horas 
trabalhadas ate a dara 

Uf" ass 
// codigo para garantir que as ferias cumpram o tempo 
minimo nos EUA 

Hu . 
// codigo para aplicar vaction ao registro de folha de 
pagamento 


) 


public void accrueEUDivisionVacation() ( 

// codigo para calcular as ferias baseando-se nas horas 
trabalhadas ate a data 

Li see 

// codigo para garantir que as ferias cumpram o tempo 
minimo nos EUA 

Ж 

// codigo para aplicar vaction ao registro de folha de 
pagamento 

ГАА 
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} 


Ocódigo ao longo de accrueUSDivisionVacatione accrueEuropeanDivisionVacation 
é praticamente o mesmo, com exceção do cálculo do tempo mínimo legal. Aquele pequeno 
algoritmo é alterado baseando-se no cargo do funcionário. 

Podemos eliminar essa duplicação óbvia aplicando o padrão Template Method. 


abstract public class VacationPolicy ( 
public void accrueVacation() ( 

calculateBaseVacationHours(); 
alterForLegalMinimums(); 


applyToPayroll(); 
) 
private void calculateBaseVacationHours() ( /* ... b a 
abstract protected void alterForLegalMinimums(); 
private void applyToPayroll() ( /* ... */ }; 


) 


public class USVacationPolicy extends VacationPolicy ( 
GOverride protected void alterForLegalMinimums() t 
// Logica usada nos EUA 


public class EUVacationPolicy extends VacationPolicy ( 
&Override protected void alterForLegalMinimums() ( 
// Logica usada na Uniao Europeia 


} 


As subclasses preenchem o “buraco” no algoritmo accrueVacation, fornecendo os únicos bits de 
informações que não são repetidos. 


Expressividade 


A maioria de nós já teve de trabalhar num código intrincado. Muitos de nós mesmos ja produzimos 
alguns códigos confusos. Escrever códigos que nós entendamos é fácil, pois quando o fazemos, 
possuímos um conhecimento profundo do problema que desejamos resolver. Mas outras pessoas 
que pegarem esse mesmo código não terão esse mesmo grau de conhecimento. 

A maioria dos custos de um projeto de software está na manutenção em longo prazo. A 
fim de minimizar os possíveis danos conforme fazemos alterações, é crucial que sejamos 
capazes de entender o que o sistema faz. Conforme os sistemas se tomam mais complexos. um 
desenvolvedor leva cada vez mais tempo para compreendê-lo, e sempre há uma chance ainda 
maior de mal entendidos. 

Portanto, o código deve expressar claramente o propósito de seu autor. Quando mais claro o 
autor tornar seu código, menos tempo outras pessoas terão de gastar para compreendê-lo. Isso 
reduz os defeitos e o custo de manutenção. Você pode se expressar através da escolha de bons 
nomes. Queremos ser capazes de ler o nome de uma classe ou função e não ficarmos surpresos 
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quando descobrirmos o que ela faz. Vocé também pode se expressar mantendo pequenas suas 
classes e funções, que costumam ser fáceis de nomear, criar e entender. 

Você também pode se expressar se usar uma nomenclatura padrão. Os Padrões de Projeto, 
por exemplo, são amplamente modos de comunicação e expressividade. Ao usar os nomes de 
padrões, como COMMAND ou VISITOR, no nome de classes que implementem tais padrões, 
você pode descrever de forma sucinta o seu projeto para outros desenvolvedores. 

Testes de unidade bem escritos também são expressivos. Por exemplo, um objetivo principal 
dos testes é funcionar como um meio de documentação. Uma pessoa que leia nossos testes 
deverá ser capaz de obter um rápido entendimento do que se trata uma classe. 

Mas a forma mais importante de ser expressivo é tentar. Muito freqüentemente, fazemos 
nosso código funcionar e, então, partimos para o problema seguinte, sem considerar o bastante 
em facilitar a leitura daquele código para outras pessoas. Lembre-se de que é muito mais provável 
que essa outra pessoa seja você. 

Portanto, tenha um pouco de orgulho em seu trabalho. Gaste um tempo em cada uma das 
suas funções e classes. Escolha nomes melhores, divida funções grandes em menores e, de forma 
geral, cuide do que você mesmo criou. Cuidar é um recurso precioso. 


Poucas classes e métodos 


Podem-se exagerar mesmo nos conceitos mais fundamentais, como a eliminação de duplicação, 
expressividade do código e o SRP. Numa tentativa de tornar nossas classes e métodos pequenos, 
podemos vir a criar estruturas minúsculas. Portanto, essa regra sugere que também devamos 
manter a mínima quantidade de funções e classes. 

Muitas classes e métodos, às vezes, são o resultado de um dogmatismo exagerado. Considere, 
por exemplo, um padrão de programação que insiste em ctiar uma interface para cada classe. 
Ou desenvolvedores que teimam em sempre separar campos e comportamentos em classes de 
dados e classes de comportamentos. Deve-se evitar tal dogmatismo e adotar uma abordagem 
mais pragmática. 

Nosso objetivo é manter nosso sistema geral pequeno ao mesmo tempo em que também 
mantemos nossas classes e funções pequenas. Lembre-se, contudo, de que essa regra é a de 
menor prioridade das quatro de Projeto Simples. Portanto, embora seja importante manter baixa a 
quantidade de classes e funções, é mais importante ter testes, eliminar a duplicação c se expressar. 


Conclusão 


Há uma série de práticas simples que possam substituir a experiência? Obviamente que não. 
Por outro lado, as práticas descritas neste capítulo e neste livro são uma forma consolidada de 
muitas décadas de experiência adquiridas pelos autores. Seguir as regras de projeto simples pode 
e realmente incentiva e possibilita desenvolvedores a aderirem a bons princípios e padrões que, 
de outra forma, levariam anos para aprender. 
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Concorrência 


por Brett L. Schuchert 


“Objetos são abstrações de procedimento. Threads são abstrações de agendamento." 
— James O. Coplien' 


1. Correspondência privada 


172 Capítulo 13; Concorrência 


Escrever programas concorrentes limpos é difícil, muito. É muito mais fácil criar um código que 
execute uma única thread, assim como um código multithread que pareça bom superficialmente, 
mas que esteja defeituoso em um nível mais baixo. Esse código funciona bem até que se use o 
sistema excessivamente. 

Neste capítulo, discutiremos a necessidade da programação concorrente e das dificultadas 
que ela representa. Depois, daremos várias sugestões para lidar com tais dificuldades e escrever 
um código concorrente limpo. E, então, fechamos com as questões relacionadas aos códigos 
concorrentes de teste. 

Concorrência limpa é um assunto complexo, válido um livro só para ele. Nossa estratégia 
aqui é apresentar uma visão geral e oferecer um tutorial mais detalhado em Concorrência II na 
página 317. Se você estiver apenas curioso sobre concorrência, este capítulo será o suficiente por 
enquanto. Se precisar de um conhecimento mais profundo, então leia também o tutorial. 


Por que concorrência? 


Concorrência é uma estratégia de desacoplamento. Ela nos ajuda a desacoplar o que é executado 
de quando é executado. Em aplicativos com apenas uma thread, o que e quando ficam tão 
fortemente acoplados que geralmente pode-se determinar o estado do aplicativo inteiro apenas 
ao olhar o rastreamento de retorno na pilha. 

Desacoplar o que de quando pode melhorar consideravelmente tanto as estruturas quanto a 
taxa de transferência dos dados de um aplicativo. De uma perspectiva estruturada, o aplicativo 
seria mais como muitos minicomputadores trabalhando juntos do que um único e grande 
main(). Isso pode facilitar a compreensão do sistema e oferecer recursos melhores para separar 
preocupações. 

Considere, por exemplo, o modelo "Servlet" padrão dos aplicativos da Web. Esses sistemas 
rodam sob o “guarda-chuva” de um contêiner Web ou EJB que gerencia parcialmente a 
concorrência para você. Os servlets são executados de forma assíncrona sempre que chega um 
pedido da Web. 

O programador do servlet não tem de gerenciar todos os pedidos que chegam. Em princípio, 
cada execução de servlet ocorre em seu próprio mundinho e fica desacoplado de todas as 
execuções de outros servlets. 

É claro que se fosse fácil assim, este capítulo não seria necessário. De fato, o desacoplamento 
oferecido pelos contêineres Web está longe de serem perfeitos. Os programadores de servlets 
têm se estar bem atentos de modo a garantir que seus programas concorrentes estejam corretos. 
Mesmo assim, as vantagens do modelo de servlet são significantes. 

Mas a estrutura não é o único motivo para se adotar a concorrência. Alguns sistemas 
possuem limites de tempo de resposta e de taxa de transferência de dados que requerem soluções 
concorrentes programadas manualmente. Por exemplo, considere um agregador de informações 
com uma única thread que obtém os dados de diferentes sites da Web e os agrupa em um resumo 
diário. Como esse sistema só possui uma thread, ele consulta um site de cada vez, sempre 
terminando em um e seguindo para o próximo. A execução diária precisa ser feita em menos 
de 24 horas. Entretanto, conforme mais websites são adicionados, o tempo também aumenta, 
até que sejam necessárias mais do que 24 horas para obter todos os dados. Ter uma única thread 
implica em muito tempo de espera nos sockets da Web para que a E/S termine. 
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Poderíamos melhorar o desempenho usando um algoritmo multithread que consulte mais de 
um website por vez. 

Ou pense num sistema que trate de um usuário de cada vez e exija apenas um segundo de tempo 
por usuário. Esse sistema é o suficiente para poucos usuários, mas conforme o número aumentar, 
também crescerá o tempo de resposta. Nenhum usuário quer entrar numa fila atrás de outros 150! 
Poderíamos melhorar o tempo de resposta tratando de vários usuários concorrentemente. 

Ou, então, imagine um sistema que interprete extensas séries de dados, mas que só ofereça 
uma solução completa após processá-las todas. Talvez poderiam processar cada série em um 
computador diferente, de modo que muitas séries de dados fossem processadas paralelamente. 


Mitos e conceitos equivocados 


E também há motivos irrefutáveis para se adotar a concorrência. Entretanto, como dissemos 
anteriormente, usar a concorrência é difícil. Se não você não for muito cauteloso, poderá criar 
situações muito prejudiciais. 

Considere os mitos e conceitos equivocados comuns abaixo: 


+ A concorrência sempre melhora o desempenho. 
Isso pode ocorrer às vezes, mas só quando houver um tempo de espera muito grande que 
possa ser dividido entre múltiplas threads ou processadores. Nenhuma situação é trivial. 


* O projeto nào muda ao criar programas concorrentes. 

De fato, o projeto de um algoritmo concorrente pode ser consideravelmente diferente do 
projeto de um sistema de apenas uma thread. O desacoplamento entre o que e quando 
costuma ter grande impacto na estrutura do sistema. 


+ Entender as questões de concorrência não é importante quando se trabalha com um 
contéiner como um da Web ou um EJB. 

Na verdade, é melhor saber apenas o que o seu contêiner está fazendo e como protegê-lo 
das questões de atualização da concorrência e do deadlock (impasse) descrito mais adiante. 


A seguir estão outras frases mais corretas em relação à criação de softwares concorrentes: 

+ A concorrência gera um certo aumento, tanto no desempenho como na criação de código 
adicional. 

* Uma concorrência correta é complexa, mesmo para problemas simples. 


+ Os bugs de concorrência geralmente não se repetem, portanto são frequentemente ignorados 
como casos únicos2 em vez dos defeitos que realmente representam. 


+ A concorrência geralmente requer uma mudança essencial na estratégia do projeto. 


Desafios 


O que torna a programação concorrente tão difícil? Considere a simples classe seguinte: 


public class X ( 
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private int lastIdUsed; 
public int getNextId() ( 
return ++lastIdUsed; 
H 
} 


Digamos que criemos uma instância de x, atribuímos 42 ао campo lastidUsed e, então a 
compartilhemos entre duas threads. Agora, suponha que ambas as threads chamem o método 
getNextId(). Haverá trés resultados possíveis: 


+ Thread um recebe o valor 43, thread um recebe 44 e last IdUsed é 44. 
+ Thread um recebe o valor 44, thread um recebe 43 e last IdUsed é 44. 
+ Thread um recebe o valor 43, thread um recebe 43 e last IdUsed é 43. 


O surpreendente terceiro resultado3 ocorre quando ambas as threads se cruzam. Isso acontece 
porque há muitos caminhos que clas podem seguir naquela linha de código Java, e alguns dos 
caminhos geram resultados incorretos. Há quantos caminhos diferentes? Para poder responder a 
essa questão, precisamos entender o que o Just-In-Time Compiler faz com o Bytecode gerado e 
o que o modelo de memória do Java considera atômico. 

Uma resposta rápida, usando o Bytecode gerado, é que há 12.870 caminhos possíveis de 
execução para aquelas duas threads executadas dentro do método getNext Td (). Se o tipo de 
last IdUsed mudar de int para long, о número de caminhos possíveis cresce para 2.704.156. 
É claro que a maioria desses caminhos gera resultados válidos. O problema é que alguns não. 


Princípios para proteção da concorrência 


A seguir está uma série de princípios e técnicas para proteger seus sistemas dos problemas de 
códigos concorrentes. 


Principio da Responsabilidade Única 


O SRPS declara que um dado método/classe/componente deve ter apenas um motivo para ser 
alterado. O modelo de concorrência é complexo o suficiente para ser uma razão e ter seu próprio 
direito de mudança e, portanto, merece ser separado do resto do código. Infelizmente, é muito 
comum que se incluam diretamente os detalhes de implementação de concorrência em outro 
código de produção. Abaixo estão alguns pontos a se levar em consideração: 


* O código voltado para a concorrência possui seu próprio ciclo de desenvolvimento, alteração 
e otimização. 


* O código voltado para a concorrência possui seus próprios desafios, que são diferentes e mais 
dificeis do que o código não voltado para concorrência. 


+ O número de maneiras pelas quais um código voltado para concorrência pode ser escrito de 
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forma errada é desafiador o bastante sem o peso extra do código de aplicação que o cerca. 


Recomendação: Mantenha seu código voltado para a concorrência separado do resto do código’. 
Solução: limite o escopo dos dados 


Como vimos, duas threads que modificam o mesmo campo de um objeto compartilhado 
podem interferir uma na outra, causando um comportamento inesperado. Uma solução é usar a 
palavra reservada synchronized para proteger uma parte crítica do código que use aquele objeto 
compartilhado. É importante restringir a quantidade dessas partes. Em quantos mais lugares os 
dados compartilhados podem vir a ser alterados, maiores serão as chances de: 


* Você se esquecer de proteger um ou mais daqueles lugares — danificando todos os códigos 
que modifiquem aqueles dados compartilhados 


+ Haver duplicação de esforços para garantir que tudo esteja protegido de forma eficiente 
(violação do Principio do Não Se Repita7, DRY, sigla em inglês); 


* Dificultar mais a determinação da origem das falhas, que já são difíceis de encontrar. 


Recomendação: Leve a sério o encapsulamento de dados; limite severamente o acesso a 
quaisquer dados que possam ser compartilhados. 


Solução: Use cópias dos dados 


Essa é uma boa maneira de evitar que os dados compartilhados compartilhem seus dados. Em 
alguns casos podem-se fazer cópias dos objetos e tratá-los como somente-leitura. Em outros 
casos podem-se fazer cópias dos objetos, colocar os resultados de múltiplas threads naquelas 
cópias e, então, unir os resultados numa única thread. 

Se houver uma maneira fácil de evitar o compartilhamento de objetos, será muito pouco 
provável que o código resultante cause problemas. Talvez você esteja preocupado com o custo de 
toda essa criação de objetos adicionais. Vale a pena experimentar para descobrir se isso é de fato um 
problema. Entretanto, se usar cópias dos objetos permitir ao código evitar a sincronização, o que se 
ganha provavelmente compensará pelas criações adicionais e o aumento da coleta de lixo. 


Solução: as threads devem ser as mais independentes 
possíveis 


Considere escrever seu código com threads de tal modo que cada thread exista em seu próprio 
mundo, sem compartilhamento de dados com qualquer outra thread. Cada uma processa um pedido 
do cliente, com todos os seus dados necessários provenientes de uma fonte não compartilhada e 
armazenada como variáveis locais. Isso faz com que cada uma das threads se comporte como se 
fossem a única thread no mundo, sem a necessidade de sincronização. 

Por exemplo, as classes que criam subclasses a partir de HttpServlet recebem todas as suas 
informações passadas por parâmetros nos métodos doGet е doPost. Isso faz cada servlet 
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se agir como se tivesse sua própria máquina. Contanto que o código no Servlet use apenas 
variáveis locais, não há como o Servlet causar problemas de sincronização. É claro que a 
maioria dos aplicativos usando servlets acabará adotando recursos compartilhados. como 
conexões de bancos de dados. 


Recomendação: Tente dividir os dados em subsistemas independentes que possam ser 
manipulados por threads independentes, possivelmente em processadores diferentes. 


Conheça sua biblioteca 


O Java 5 oferece muitas melhorias para o desenvolvimento concorrente em relação às versões 
anteriores. Há várias coisas a se considerar ao criar código com threads em Java 5: 


* Use as coleções seguras para threads fornecidas. 
* Use o framework Executor para executar tarefas não relacionadas. 
* Use soluções non-blocking sempre que possível. 


* Classes de bibliotecas que não sejam seguras para threads. 


Coleções seguras para threads 


Quando o Java estava no início, Doug Lea escreveu o livro precursor Concurrent Programming, 
com o qual juntamente ele desenvolveu várias coleções seguras para threads, que mais tarde se 
tornou parte do JDK no pacote java.util.concurrent. As coleções neste pacote são seguras para 
situações multithread e funcionam bem. Na verdade, a implementação de ConcurrentHashMap 
roda melhor do que a HashMap em quase todos os casos. Além de permitir leitura e escrita 
concorrente simultánea e possuir métodos que suportam operações compostas comuns que, caso 
contrário, não seriam seguras para thread. Se o Java 5 for o ambiente de implementação, comece 
com a ConcurrentHashMap. 

Há diversos outros tipos de classes adicionados para suportar o modelo de concorrência 
avançado. Aqui estão alguns exemplos: 


bloqueio que pode ser colocado em um método e liberado em outro. 


Semaphore implementação do semáforo clássico, um bloqueio com um contador. 


CountDownLatch | bloqueio que espera por um número de eventos antes de liberar todas as 
threads em espera. Isso permite que todas as threads tenham a mesma 
chance de iniciar quase ao mesmo tempo. 


Recomendação: Revise as classes disponíveis para você. No caso do Java, familiarize-se com 
as classes java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks. 
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Conheça seus métodos de execução 


Há diversas maneiras de dividir o comportamento em um aplicativo concorrente. Para falarmos 
sobre eles, precisamos entender algumas definições básicas. 


Recursos limitados (Bound Resources) recursos de um tamanho ou número fixo usado 
em um ambiente concorrente. 
Conexões de banco de dados e buffers de 
leitura/escrita de tamanho fixo são alguns 
exemplos. 
Exclusão mútua (Mutual Exclusion) apenas uma thread de cada vez pode acessar 
dados ou recursos compartilhados. 


Espera indefinida (Starvation) uma thread ou um grupo de threads não pode 
prosseguir por um tempo excessivamente longo 
ou indefinidamente. Por exemplo: sempre 
deixar que threads de execução rápida rodem 
primeiro pode fazer com que threads que levem 
mais tempo tenham de esperar muito caso as de 
execução rápida forem infinitas. 


duas ou mais threads esperam que a outra 
termine. Cada thread possui um recurso que a 
outra precisa e nenhuma delas pode terminar 
até obter o tal recurso. 


threads num entrave, cada uma tentando 
fazer seu trabalho, mas se deparando com 
outras “no caminho”. Devido à repercussão, 
as threads continuam tentando progredir, mas 
não conseguem por um tempo excessivamente 
longo ou indefinido. 


Bloqueio infinito (Deadlock) 


Dadas essas definições, agora podemos discutir os modelos de execução usados na programação 
concorrente. 


Producer-Consumer? 


Uma ou mais threads producer criam alguma tarefa e a colocam em um buffer ou fila de espera. 
Uma ou mais threads consumer pegam a tarefa da fila de espera e a finalizam. A fila de espera 
entre as producers e as consumers é um bound resource (recurso limitado). Isso significa que as 
producers devem esperar por espaco livre na fila de espera antes de colocar algo nela, e que as 
consumers devem esperar até que haja algo na fila de espera para ser recuperado. A coordenação 
entre as threads producers e consumers através da fila de espera requer que elas enviem sinais 
entre si. As producers escrevem na fila de espera е sinalizam que ela nào está mais vazia. As 
consumers lêem a partir da fila de espera e sinalizam que ela não está mais cheia. Ambas ficam 
na espera pela sinalização para poderem continuar. 


178 Capítulo 13: Concorrência 


Leitores e escritores!’ 


Quando você tem um recurso compartilhado que serve principalmente como uma fonte de 
informações para leitores, mas que de vez em quando é atualizada por escritores, a taxa de 
transferência dos dados é um problema. Isso porque ela pode gerar espera indefinida (starvation) 
e acúmulo de informações velhas, Permitir atualizações pode afetar a taxa de transferência dos 
dados. Coordenar os leitores de modo que não leiam algo que um escritor esteja atualizando, e 
vice-versa, é um equilíbrio difícil. Os escritores tendem a bloquear muitos leitores por bastante 
tempo, afetando assim a taxa de transferência dos dados. 

O desafio é equilibrar as necessidades tanto dos leitores como dos escritores para satisfazer 
a operação correta, oferecer uma taxa de transferência de dados razoável e evitar a espera 
indefinida. Uma estratégia simples é fazer os escritores esperarem até que não haja mais leitores 
e, então, permitir que façam a atualização. Entretanto, se houver leitores constantes, os escritores 
ficarão numa espera indefinida. Por outro lado, se houver escritores frequentemente e eles tiverem 
prioridade, o impacto será na taxa de transferência de dados. Encontrar esse equilíbrio e evitar as 
questões de atualização concorrente é do que trata o problema. 


Dining Philosophers (Problema dos Filósofos)” 


Imagine alguns filósofos sentados em uma mesa redonda. Coloca-se um garfo à esquerda de cada 
um. Há uma grande tigela de espaguete no meio da mesa. Os filósofos passam o tempo pensando, 
a menos que estejam com fome. Quando isso acontece, cada um pega seu garfo e come. Um 
filósofo não pode comer a menos que esteja segurando dois garfos. Se o filósofo à sua direita 
ou esquerda já estiver usando um dos garfos que ele precisa, ele deverá esperar até que aquele 
filósofo termine de comer e repouse o garfo novamente na mesa. 

Quando um filósofo acaba de comer, ele devolve seu grafo à mesa e espera ficar com 
fome novamente. Substitua os filósofos por threads e os garfos por recursos. Esse problema é 
semelhante a muitos aplicativos corporativos nos quais os processos competem pelos recursos. 
A menos que tenha sido meticulosamente desenvolvido, os sistemas que competem dessa forma 
podem sofrer deadlock, livelock e queda na taxa de transferência de dados e no desempenho. 

A maioria dos problemas de concorrência que você encontrará será uma variação desses três. 
Estude esses algoritmos e crie soluções usando-os à sua maneira, de modo que, ao se deparar 
com problemas de concorrência, você esteja mais preparado para resolvê-lo. 


Recomendação: Aprenda esses algoritmos básicos e entenda suas soluções. 


Cuidado com dependências entre métodos 
sincronizados 


Dependências entre métodos sincronizados causam pequenos bugs no código concorrente. 
A linguagem Java possui a palavra reservada synchronized, que protege um único método. 
Entretanto, se houver mais de um método sincronizado na mesma classe compartilhada, então 
seu sistema pode ser sido escrito incorretamente". 


а TO 
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Recomendação: evite usar mais de um método em um objeto compartilhado. 


Haverá vezes em que você deverá usar mais de um método em um objeto compartilhado. 
Neste caso, há três formas de deixar o código certo: 


« Bloqueio voltado para o cliente: faça o cliente bloquear o servidor antes de chamar o primeiro 
método e certifique-se de que o bloqueio inclua o código que chama o último método. 


+ Bloqueio voltado para o servidor: dentro do servidor, crie um método que bloqueie o servidor, 
chame todos os métodos e, então, desbloqueie. Faça o cliente chamar o novo método. 


+ Servidor extra: crie um servidor intermediário que efetue o bloqueio. Esse é um exemplo de 
bloqueio voltado para o servidor, no qual o servidor original não pode ser alterado. 


Mantenha pequenas as seções sincronizadas 


A palavra reservada synchronized adiciona um bloqueio. Todas as seções do código protegidas 
pelo mesmo bloqueio garantem que há apenas uma thread em execução para todas elas num 
dado momento. Os bloqueios são prejudiciais, pois causam atrasos е adicionam trabalho extra. 
Portanto, não queremos amontoar nosso código com instruções synchronized. Por outro lado, 
devem-se proteger seções críticas. Sendo assim, desejamos criar nosso código com o menor 
número possível de seções críticas. 

Alguns programadores ingênuos tentam conseguir isso tornando as seções críticas muito 
grandes. Entretanto, estender a sincronização além da seção crítica mínima aumenta os conflitos 
e prejudica o desempenho". 


Recomendação: mantenha suas seções sincronizadas as menores possíveis. 
É difícil criar códigos de desligamento corretos 


Criar um sistema que deva ficar para sempre executando é diferente de criar algo que funcione 
por um tempo e, então, desligue de maneira adequada. 

Obter um desligamento adequado pode ser dificil. Dentre os problemas comuns estão o 
deadlock'5, com threads esperando por um sinal que nunca chega para continuar. Рог exemplo, 
imagine um sistema com uma thread pai que gera diversas threads filhas e, então, antes de liberar 
seus recursos e desligar, espera que todas elas finalizem, E se uma das threads filhas sofrer 
deadlock? O pai esperará para sempre e o sistema jamais desligará. 

Ou pense num sistema semelhante que tenha sido instruído a desligar. A thread pai diz a todas 
as suas filhas para abandonar suas tarefas e finalizar. Mas e se duas das filhas estiverem operando 
como um par producer/consumer? Suponha que a thread producer receba o sinal da thread pai e 
desligue imediatamente. A consumer talvez estivesse esperando uma mensagem da producer e 
bloqueada de modo que não consiga receber o sinal para desligamento. 

Ela ficaria presa esperando pela producer e nunca finalizar, ev itando que a thread pai 
também finalize. 

Situações como essa não são tão incomuns assim. Portanto, se você precisar criar um código 
concorrente que exija um desligamento apropriado, prepare-se para passar a maior parte de seu 
tempo tentando fazer com que o desligamento ocorra com sucesso. 
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Recomendação: Pense o quanto antes no desligamento e faça com que ele funcione com êxito. 
Vai levar mais tempo do que você espera. Revise os algoritmos existentes, pois isso é mais dificil 
do que você imagina. 


Teste de código com threads 


Considerar que o código está correto, impossível. Testes não garantem que tudo esteja correto. 
Entretanto, eles podem minimizar os riscos. Isso tudo é válido para uma solução com uma única 
thread. Enquanto houver duas ou mais threads usando o mesmo código e trabalhando com os 
mesmos dados compartilhados, as coisas se tornam consideravelmente mais complexas. 


Recomendação: Crie testes que consigam expor os problemas e, então. execute-os frequentemente, 
com configurações programáticas e configurações e carregamentos de sistema. Se o teste falhar, 
rastreie a falha. Não ignora uma falha só porque o teste não a detectou no teste seguinte. 


É muito para se assimilar. Abaixo estão algumas recomendações mais detalhadas: 


* Trate falhas falsas como questões relacionadas às threads. 
* Primeiro, faça com que seu código sem thread funcione. 
+ Torne seu código com threads portátil. 

* Torne seu código com threads ajustável. 

* Rode com mais threads do que processadores. 

* Rode em diferentes plataformas. 

* Altere seu código para testar e forçar falhas. 


Trate falhas falsas como questões relacionadas às threads. 


O código que usa threads causa falhas em coisas que “simplesmente não falham”. A maioria dos 
desenvolvedores não entende como o uso de threads interage com outros códigos (incluindo seus 
autores). Os bugs em códigos com threads podem mostrar seus sintomas uma vez a cada mil ou 
milhares de execuções. 

Tentativas para repetir os erros no sistema podem ser frustrantes. Isso geralmente leva os 
desenvolvedores a descartarem as falhas como raios cósmicos, uma pequena falha no hardware ou 
outro tipo de “casos isolados”. É melhor assumir que não existem casos isolados, os quais quanto mais 
forem ignorados, mais o código será construído no topo de uma abordagem possivelmente falha. 


Recomendação: Não ignore falhas de sistema como se fossem casos isolados. 


Primeiro, faça com que seu código sem thread funcione 


Isso pode parecer óbvio, mas não custa nada repetir. Certifique-se de que o código funcione sem 
threads. Geralmente, isso significa criar POJOs que são chamados pelas suas threads. 
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Os POJOs não enxergam as threads e, portanto, podem ser testados fora do ambiente com threads. 
Quando mais locais no seu sistema você conseguir colocar tais POJOs, melhor. 


Recomendação: Não procure bugs não relacionados a threads com os relacionados a elas ao 
mesmo tempo. Certifique-se de que seu código funcione sem threads. 


Torne seu código com threads portátil 


Criar o código que suporte concorrência de modo que possa ser executado em diversas 
configurações: 


* Uma thread, várias threads, variações conforme a execução. 

* O código com threads interage com algo que possa ser tanto real como artificial. 
« Execute com objetos artificiais que rodem de forma rápida. lenta e variável. 

+ Configure testes de modo que possam rodam para um certo número de iterações. 


Recomendação: Faça de seu código com threads especialmente portátil de modo que possa 
executá-lo em várias configurações. 


Torne seu código com threads ajustável 


Obter o equilíbrio certo entre as threads requer testar e errar. O quanto antes, encontre maneiras 
de cronometrar o desempenho de seu sistema sob variadas configurações. Possibilite para que 
188 threads possam ser facilmente ajustadas. Considere permitir a alteração enquanto o sistema 
estiver em execução. 

Considere permitir um auto-ajuste baseando-se na taxa de transferência de dados e no uso do sistema, 


Rode com mais threads do que processadores. 


Coisas acontecem quando o sistema alterna entre as tarefas. A fim de incentivar a troca (swapping) 
de tarefas, execute mais threads do que os processadores ou núcleos presentes. Quanto mais 
frequentemente suas tarefas alternarem, mais provavelmente você descobrirá partes do código 
que precisam de uma seção crítica ou que causa um deadlock. 


Rode em diferentes plataformas 


Em meados de 2007. elaboramos um curso sobre programação concorrente. O curso foi 
desenvolvido essencialmente sob a plataforma OS X. Apresentamos à turma usando o Windows 
XP rodando sob uma máquina virtual (VM, sigla em inglês). Criamos testes para demonstrar que 
as condições para falhas ocorriam mais frequentemente num ambiente OS X do que em um XP. 
Em todos os casos, sabia-se que o código testado possuía erros. Isso só reforçou o fato de que sistemas 
operacionais diferentes têm diferentes políticas de tratamento de threads, cada uma afetando a execução 
do código. O código multithread se comporta de maneira diferente em ambientes diversos. 

Você deve rodar seus testes em cada possível ambiente de implementação. 


182 Capítulo 13: Concorrência 


Recomendação: Execute o quanto antes e frequentemente seu código com threads em todas as 
plataformas finais. 


Altere seu código para testar e forçar falhas 


É normal que as falhas se escondam em códigos concorrentes. Testes simples não costumam 
expô-las. 

Na verdade, elas costumam se ocultar durante o processamento normal e talvez só apareçam uma 
vez em algumas horas, ou dias, ou semanas! 

O motivo que torna os bugs em threads raros, esporádicos e de rara reincidência é que muito 
poucos caminhos dos milhares possíveis através de uma seção realmente falham. Portanto, a 
probabilidade de se tomar um caminho falho é extraordinariamente pequena. Isso dificulta muito 
a detecção e a depuração. 

Como você poderia aumentar suas chances de capturar tais raras ocorrências? Você pode alterar 
seu código e forçá-lo a rodar em diferentes situações através da adição de chamadas a métodos 
como Object .wait (), Object. sleep(), Object .yield() eObject.priority(). 
Cada um deles pode afetar a ordem da execução, aumentando assim as chances de detectar uma 
falha. E melhor que o código falhe o quanto antes. 

Há duas opções para alteração: 


* Manualmente 
«Automatizada 


Manualmente 


Você pode inserir manualmente as chamadas a wait(), sleep(), yield()e priority(). É bom fazer 
isso quando estiver testando uma parte capciosa do código. 
O exemplo abaixo faz exatamente isso: 


public synchronized String nextUrlOrNull() ( 
if(hasNext()) ( 
String url = urlGenerator.next(); 
Thread.yield(); // inserido para testar. 
updateHasNext(); 
return url; 
} 
return null; 
} 


A chamada ao yield() inserida mudará os caminhos de execução tomados pelo código e 
possivelmente fará o código falhar onde não havia erro antes. Se isso ocorrer, não foi porque 
você adicionou uma chamada ao yield()". mas porque seu código já possuía a falha e isso 
simplesmente a tornou evidente. 
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Há muitos problemas com essa abordagem: 


“É preciso encontrar manualmente os locais onde fazer isso. 

* Como saber onde e qual tipo de chamada colocar? 

* Deixar tal código em um código de produção sem necessidade atrasa o código. 

* Essa abordagem é um tiro no escuro. Você pode ou não encontrar falhas. De fato, as 
probabilidades não estão a seu favor. 


Precisamos de uma forma de fazer isso durante a fase de testes, e não na de produção. Também 
temos de misturar com facilidade as configurações entre as diferentes execuções, o que aumentará 
as chances de encontrar erros no todo. 

Claramente, se dividirmos nosso sistema em POJOs que não saibam nada sobre as threads e as 
classes que controlam o uso daquelas, será mais fácil encontrar os locais apropriados para alterar 
o código. Ademais, poderiamos criar muitas variações de testes que invoquem os POJOs sob 
sistemas diferentes de chamadas a sleep. yield, e assim por diante. 


Automatizada 


Você poderia usar ferramentas como um framework orientado a aspecto, CGLIB ou ASM para 
alterar seu código de forma automática. Por exemplo, você poderia usar uma classe com um 
único método: 


public class ThreadJigglePoint ( 
public static void jiggle() ( 
) 

j 


Vocé pode adicionar chamadas a ele em vários lugares de seu código: 


public synchronized String nextUrlOrNull() ( 
if(hasNext()) ( 
ThreadJiglePoint.jiggle(); 
String url = urlGenerator.next(); 
ThreadJiglePoint.jiggle(); 
updateHasNext (}; 
ThreadJiglePoint.jiggle(); 
return url; 
) 
return null; 
k 


Agora você usa um aspecto simples que selecione aleatoriamente entre fazer nada, dormir ou 
ficar passivo. 

Ou imagine que a classe ThreadJigglePoint tem duas implementações. A primeira implementa 
jiggle, não faz nada e é usada na produção. A segunda gera um número aleatório para selecionar 
entre dormir, ficar passivo ou apenas prosseguir. Se executar seus testes mil vezes com essa 
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aleatoriedade, talvez você revele algumas falhas. Se o teste passar, pelo menos você pode dizer 
que teve a devida diligência. Embora um pouco simples, essa poderia ser uma opção razoável em 
vez de uma ferramenta mais sofisticada. 

Há uma ferramenta chamada ConTest'*, desenvolvida pela IBM que faz algo semelhante. mas 
com um pouco mais de sofisticação. 

A questão é testar o código de modo que as threads executem em ordens diferentes em 
horas diferentes. A combinação de testes bem escritos e esse processo podem aumentar 
consideravelmente as chances de encontrar erros. 


Recomendação: Use essas estratégias de testes para desmascarar erros. 


Conclusão 


É difícil conseguir um código concorrente correto. Um código simples de se seguir pode se 
tornar um pesadelo quando múltiplas threads e dados compartilhados entram em jogo. Se você 
estiver criando esse tipo de código, é preciso mantê-lo rigorosamente limpo. ou haverá falhas 
sutis e não frequentes. 

Primeiro e acima de tudo. siga o Princípio da Responsabilidade Única. Divida seu sistema 
em POJOs que separem o código que enxerga threads daquele que as ignora. Certifique-se de 
que você está testando apenas seu código que usa threads e nada mais. Isso sugere que ele deva 
ser pequeno e centralizado. Tenha em mente as possíveis fontes de problemas com concorrência: 
múltiplas threads operando em dados compartilhados ou usando uma fonte de recursos em 
comum. Casos de limites, como desligar adequadamente ou terminar a iteração de um loop, 
pode ser um risco a mais. 

Estude sua biblioteca e conheça os algoritmos essenciais. Entenda como alguns dos recursos 
oferecidos por ela dão suporte à solução de problemas semelhantes aos proporcionados 
algoritmos essenciais. 

Aprenda como encontrar partes do código que devam ser bloqueadas e as bloqueie — faça isso 
apenas com as que realmente precisem ser. Evite chamar uma seção bloqueada a partir de outra, 
pois isso requer um grande entendimento se algo deve ou não ser compartilhado. Mantenha a 
quantidade de objetos compartilhados e o escopo do compartilhamento o mais curto possível. 
Altere os modelos dos objetos com os dados compartilhados para acomodar os clientes em vez 
de forçar estes a gerenciar o estado compartilhado. 

Problemas surgirão. Os que não aparecem logo geralmente são descartados como casos 
isolados. Esses famosos “casos isolados” costumam ocorrer apenas na inicialização ou em 
momentos aleatórios. Portanto, é preciso ser capaz de rodar repetidamente e constantemente seu 
código com threads em muitas configurações e plataformas. A capacidade de ser testado, que 
vem naturalmente com as Três Leis do TDD, implica certo nível de portabilidade, o que oferece 
o suporte necessário para executar o código numa gama maior de configurações. 

Você pode melhorar consideravelmente suas chances de encontrar erros se tomar seu 
tempo para manipular seu código. Isso pode ser feito manualmente ou com alguma ferramenta 
automatizada. Invista nisso o quanto antes. É melhor ter executado seu código com threads o 
máximo possível antes de colocá-lo na fase de produção. 


14 


Refinamento Sucessivo 


Caso de estudo de um analisador sintático de parâmetro em uma linha de comando 


Este capítulo é um caso de estudo sobre como obter um refinamento com êxito. Você verá um módulo 
que começará bem, mas não progredirá mais. Então, verá como ele será refatorado e limpo. 
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A maioria de nós, de tempos em tempos, tem de analisar a sintaxe dos parámetros na linha de 
comando. Se não tivermos um utilitário adequado, então simplesmente deixamos passar o array 
de strings passado à função main. Há vários utilitários bons disponíveis, mas nenhum deles faz 
exatamente o que quero. Portanto, decidi criar o meu próprio. que chamarei de Args. 

E muito simples usá-lo. Basta criar uma classe Args com os parâmetros de entrada e uma 
string de formato, e, então, consultar a instância Args pelos valores dos parâmetros. 

Por exemplo, veja o exemplo abaixo: 


Listagem 14-1 
Uso simples de args 


public static void main(String[] args) ( 
try ( 

Args arg = new Args("1,p#,d*", args); 

boolean logging = arg.getBoolean('l'); 

int port arg.getInt('p'); 

String directory = arg.getString('d'); 

executeApplication(logging, port, directory): 

catch (ArgsException e) ( 

System.out.printfi'Argument error: $sin', e.errorMessagei)); 


Viu a simplicidade? Apenas criamos uma instáncia da classe Args com dois parámetros. O 
primeiro é a string do formato, ou esquema: “1,p#,d*.” Ela declara trés parâmetros na linha 
de comando. O primeiro, -1. é booleano; o segundo, -p, é um inteiro; e o terceiro, -d, é uma 
string. O segundo parámetro do construtor Args é um array simples passado como parâmetro na 
linha de comando para main. 

Se o construtor retornar sem lançaruma ArgsExcept i on, então a linha de comando da entrada 
é analisada e a instância Args fica pronta para ser consultada. Métodos como aetBoolean, 
getInteger € getString nos permite acessar os valores dos argumentos pelos nomes. 

Se houver um problema, seja na string de formato ou nos parâmetros da linha de comando, 
será lançada uma ArgsExcept ion. Para uma descrição adequada do que deu errado, consulte o 
método errorMessage da exceção. 


Implementação de Args 


A Listagem 14.2 é a implementação da classe Args. Leia-a com bastante atenção. Esforcei-me 
bastante no estilo e na estrutura, e espero que valha a pena. 


Listagem 14-2 
Args. java 


package com.cbjectmentor .utilities.args: 


import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; 
import java.util.*; 


public class Args ( 
private Map«Character, ArgumentMarshaler» marshalers; 
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Listagem 14-2 
Args.java 


private Set«Character» argsFound; 
private ListIterator<String> currentArgument ; 


public Args(String schema, String[] args) throws ArgsException 
marshalers = new HashMap<Character, ArgumentMarshaler>(1; 
argsFound - new HashSet«Character»(); 


parseSchema (schema) ; 
parseArgumentStrings (Arrays .asList (args) ) ; 
} 


private void parseSchema(String schema) throws ArgsException ( 
for (String element : schema.split(",")) 
if (element.length() > 0) 
parseSchemaElement (element, trim() ) ; t 
i 


private void parseSchemaElement (St 

char elementId = element .charAt (O 
String elementTail = element. substring'(1); 
validateSchemaElementId (element Id) ; 
if (elementTail.length() == 0) 

marshalers.put (element Id, new BooleanArgumentMarshaler()); 
else if (elementTail.equals("*")) 

marshalers.put (elementId, new StringArgumentMarshaler(]]; 
else if (elementTail.equals("#")) 

marshalers.put (element Id, new IntegerArgumentMarshaler()) ; 
else if (elementTail.equals("##")) 

marshalers.put(elementId, new DoubleArgumentMarshaler()); 
else if {elementTail.equals("[*]")) 

marshalers.put(elementld, new StringàrrayArgumentMarshaler(]]; 
else 

throw new ArgsException (INVALID ARGUMENT FORMAT, elementId, elementTaill; 


ing element) throws ArgsException ( 


1 


private void validateSchemaElementId(char elementId) throws ArgsException ( 
if (!Character.isLetter (element1dj) 
throw new ArgsException(INVALID ARGUMENT NAME, elementId, null); 


1 
private void parseArgumentStrings(List<String> argsList} throws ArgsException 


for (currentArgument = argsList.listIterator(); currentArgument.hasNext () ; ) 
{ 
String argString = currentArgument .next!); 
if (argString.startswith("-")) { 
parseArgumentCharacters (argString.substring(1)); 
+ else t 
currentAroument previous i); 
break; 
) 


{ 
j 
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Listagem 14-2 
Args.java 


ate void parseArgumentCharacters(String argChars) throws ArgsException { 
т (int i = 0; i < argChars.length(); i++) 
parseArgumentCharacter (argChars .chazrAc (i!) ; 


private void parseargumentCharacter (char argChar) throws ArgsException ( 
ArgumentMarshaler m = marshalers.get(argChar!; 
if (m == null) ( 
throw new ArgsException (UNEXPECTED ARGUMENT, argChar, null}; 
else { 
argsFound.add (argChar! : 
try ( 
m.set (current&rgument ) ; 
} catch (ArgsException e) ( 
€.setErrorArgumentId(argChar) ; 
throw e; 
H 


) 


public boolean has(char arg) { 
return argsFound.contains(arg); 
) 


public int nextArgument() ( 
return currentArgument .nextIndex() ; 
) 


public boolean getBcolean(char arg) { 
return BooleanArgumentMarshaler .getvalueimarshalers.get largi); 
) 


public String getString(char arg) ( 
return StringArgumentMarshaler.getValue (marshalers.get (arg)); 
) 


public int getInt(char arg) { 
return IntegeràrgumentMarshaler.getValue (marshalers.get (arg) ) ; 
j 


public double getDoubleichar arg) ( 
return DoubleArgumentMarshaler.getValue (marshalers.get (arg) ) : 


public String[] getStringarray (char arg) ( 


return StringArrayArgumentMarshaler.getValue(marshalers. get (arg)) ; 


} 


Note que você consegue ler este esse código de cima para baixo sem ter de saltar muito para 
lá e para cá. Uma coisa que você teve de olhar um pouco mais a à frente é a definição de 
ArgumentMarshaler, que deixei de fora propositalmente. Após ter lido com atenção esse código, 
você deve ser capaz de entender o que fazem a interface argument Marshal er e seus derivados. 
Irei lhe mostrar alguns deles agora (Listagem 14-3 até 14.6). 
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Listagem 14-3 
ArgumentMarshaler . java 
public interface ArgumentMarshaler ( 
void set (Iterator<String> currentArgument) throws ArgsException; 
) 
Е 


Listagem 14-4 
ArgumentMarshaler. java 


public class BooleanArgumentMarshaler implements ArgumentMarshaler { 
private boolean bocleanValue = false; 


public void set (Iterator<String> currentArgument) throws ArgsException 
booleanValue = true; 


) 


public static boolean getValue(ArgumentMarshaler am) ( 


if (am != null && am instanceof BooleanArgumentMarshaler) 
return [(BooleanArgumentMarshaler) am) .booleanValue; 
else 
return false; 


( 


Listagem 14-5 
StringArgumentMarshaler.java 


import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; 


public class StringArgumentMarshaler implements ArgumentMarshaler ( 
private String stringValue = ""; 


public void set(Iterator«String» currentArgument) throws ArgsException 
try { 


stringValue = currentArgument .next (); 
} catch (NoSuchElementException e) { 
throw new ArgsException(MISSING STRING); 


H 


public static String getValue(ArgumentMarshaler am) ( 
if (am != null && am instanceof StringArgumentMarshaler) 


return ((StringArgumentMarshaler) am).stringValue; 
else 


return ""; 
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Listagem 14-6 
IntegerArgumentMarshaler. java 


import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; 


public class IntegerArgumentMarshaler implements ArgumentMarshaler ( 
private int intValue - 0; 


public void set(Iterator«String» currentArgument) throws ArgsException { 
String parameter - null; 


try ( 
parameter = currentàrgument.next(]; 
intValue = Integer.parseInt (parameter) ; 


catch (NoSuchElementException е) ( 

throw new ArgsException (MISSING INTEGER); 

catch (NumberFormatExcepticn e) ( 

throw new ArgsException (INVALID. INTEGER, parameter); 


} 


public static int getValue(ArgumentMarshaler am) ( 
if (am !- null && am instanceof IntegerArgumentMarshaleri 
return ({IntegerArgumentMarshaleri am).intValue; 
else 
return 0; 


O outro ArgumentMarshaler derivado simplesmente replica esse padrão para arrays tipo doubles 
€ String, e serve para encher esse capítulo. Deixarei-os para que você pratique neles. 

Outra coisa pode estar lhe incomodando: a definição das constantes dos códigos de erro. Elas 
estão na classe ArgsException (Listagem 14.7). 


Listagem 14-7 


ArgsException. java 


import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; 


public class IntegerArgumentMarshaler implements ArgumentMarshaler ( 
private int intValue - 0; 


public void set(Iterator«String» currentArgument) throws ArgsException | 
String parameter - null; 
try { 

parameter = currentArgument next (); 

intValue = Integer .parseInt (parameter) ; 

catch (NoSuchElementException e! ( 

throw new ArgsException(MISSING INTEGER): 

catch (NumberFormatException e) í 

throw new ArgsException (INVALID INTEGER, parameter); 
) 

} 


public static int getValue(ArgumentMarshaler am) { 
if (am null && am instanceof IntegerArgumentMarshaleri 
return ((IntegerArgumentMarshaler} am) .intValue; 
else 
return 0; 
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Listagem 14-7 (continuação) 
ArgsException. java 


public ArgsException(ErrorCode errorCode, 
char errorArgumentId, String errorParameter) { 
this.errorCode - errorCode; 
this.errorParameter = errorParameter; 
this.errorArgumentId = errorArgumentld; 


public char getErrorArgumentId() í 
return erroràrgumentld; 


public void setErrorArgumentId(char errorArgumentId) { 
this.errorArgumentId = errorArgumentld; 


public String getErrorParameter() ( 
return errorParamerer; 
1 


public void setErrorParameter (String errorParameter) { 
this.errorParameter = errorParameter; 
} 


public ErrorCode getErrorCode() { 
return errorCode; 


) 


publie void setErrorCode(ErrorCode errorCode) { 
this.errorCode - errorCode; 
) 


public String errorMessage() ( 
switch (еггогСоде) { 

case OK: 
return "TILT: Should not get here.'; 

case UNEXPECTED ARGUMENT: 
return String. format ("Argument -$c unexpected.", errcrargumentId) ; 

case MISSING STRING: 
return String. format ("Could not find string parameter for -&c.", 

errorArgument Id) ; 


case INVALID_INTEGER: 
return String. format ("Argument -%c expects an integer but was '%з'.”, 
errorArgumentId, errorParameter) ; 
case MISSING_INTEGER: 
return String. format ("Could not find integer parameter for -$c.", 
erroràrgument Id); 
case INVALID_DOUBLE: 
return String. format ("Argument -tc expects a double but was '$s'.", 
errorArgumentId, errorParameter) ; 


case MISSING DOUBLE: 
return String.format ("Could not find double parameter for -$c.", 
errorArgunent Id) ; 
case INVALID ARGUMENT NAME: 
return String.format("'$c' is not a valid argument name.*, 
errorArgument Id) ; 
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Listagem 14-7 (continuação) 
ArgsException. java 


case INVALID ARGUMENT FORMAT: 
return String. format ("'#5' is not 
errorParame 


a valid argument format.", 


r); 


) 
return ""; 


public enum ZrrorCode | 
OK, INVALID ARGUMENT FORMAT, UNI 
MISSING STRING, 
MISSING INTEGER, INVALID INTEGER, 
MISSING DOUBLE, INVALID DOUBLE) 


RGUMENT, INVALID ARGUMENT NAME, 


É impressionante a quantidade de código nec: ja para esclarecer os detalhes deste simples conceito. 
Um dos motivos disso é que estamos usando uma linguagem particularmente prolixa. Como Java é 
uma linguagem estática, é preciso digitar muitas palavras de modo a satisfazer o sistema de tipos. Em 
linguagens como Ruby, Python ou Smalltalk, esse programa fica muito menor". 

Leia o código novamente. Atente especialmente para os nomes escolhidos, o tamanho das 
funções e o formato do código. Se você for um programador experiente, talvez faça uma crítica 
aqui e ali e em relação ao estilo ou à estrutura. De modo geral, entretanto, espero que perceba 
que este programa está bem escrito e possui uma estrutura limpa. 

Por exemplo, deve ficar óbvio como adicionar um novo tipo de parâmetro, como uma data 
ou um número complexo, e que essa inserção exige pouco esforço. Em suma, simplesmente 
bastaria criar um derivado de ArgumentMarshaler. uma nova função getXXX e uma nova 
instrução case na função parseSchemaElement. Provelmente haveria também um na nova 
ArgsException.ErrorCode e uma nova mensagem de erro. 


Como fiz isso? 


Permita-me tirar sua dúvida. Eu não criei simplesmente esse programa do início ao fim neste 
formato que ele se encontra agora. E, mais importante, não espero que você seja capaz de 
escrever programas limpos e elegantes de primeira. Se aprendemos algo ao longo das últimas 
décadas, é que programar é mais uma arte do que ciência. Para criar um código limpo, é preciso 
criar primeiro um “sujo” e, então limpá-lo. 

Isso não deveria ser surpresa para você. Aprendemos essa verdade na escola quando nossos professores 
tentavam (em vão) nos fazer escrever rascunhos de nossas redações. O processo, eles diziam, era 
criar um rascunho e, depois. um segundo e, então, vários outros até que chegássemos à versão final. 
Escrever redações limpas, eles tentavam nos dizer, é uma questão de refinamento constante. 

A maioria dos programadores iniciantes (assim como muitos alunos do ensino fundamental) 
não segue muito bem esse conselho. Eles acreditam que o objetivo principal é fazer o programa 
funcionar e, uma vez conseguido, passam para a tarefa seguinte, deixando o programa “que 
funciona” no estado em que estiver. A maioria dos programadores experientes sabe que isso é 
suicídio profissional. 
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Args: 0 rascunho 


A Listagem 14.8 mostra uma versão anterior da classe Args. Ela “funciona” e está uma zona. 


Listagem 14-8 
Args.java (primeiro rascunho) 


import java.text.ParseException; 
import java.util 


public class Args ( 
private String schema; 
private String[] args 
private boolean valid - true; 
private Ser<Character> unexpectedArguments = new TreeSet<Character>(); 
private Map<Character, Boolean» booleanargs = 
new HashMap<Character, Воо1еап>(); 
private Map<Character, String» stringArgs = new HashMap«Character, String>{); 
private Map<Character, Integer» intArgs = new HashMap<Character, Integer>(); 
i Set<Character> argsFound = new HashSet«Character»!]; 
int currenthrgument; 
private char errorArgumentId = ':0'; 
private String errorParameter = "TILT"; 
private ErrorCode errorCode = ErrorCode.0K; 


private enum ErrorCode ( 
OK. MISSING STRING, MISSING INTEGER, INVALID INTEGER, UNEXPECTED. ARGUMENT) 


public Args(String schema, String|] args) throws ParseException ( 
this.schema - schema; 
this.args - args; 
valid = parsel); 
} 


private boolean parse() throws ParseException { 
if (schema.length(| == 0 && args.length == 0) 
return true; 
parseSchema () ; 
try 6 
parseArguments i); 
} catch (ArgsException e) { 
} 
return valid; 
) 


private boolean parseSchema() throws ParseException ( 
for (String element : schema.split(",")) ( 
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Listagem 14-8 (continuação) 


Args.java (primeiro rascunho) 


if (element. length() > 0) ( 
String trimmedElement = element.trim(); 
parseSchemaElement (trimmedElement ) ; 
1 
} 
return true; 
} 


private void parseSchemaElement (String element} throws ParseException { 
char elementId = element .charat (0); 
String elementTail = element .substring(1): 

lidateSchemaElement Td (element Idi ; 

if (isBooleanSchemaElement (elementTail)) 
parseBooleanSchemaElement (element Id) ; 

else if (1sStringSchemaElement (elementTail)) 
parseStringSchemaElement (element Id); 

else if (isIntegerSchemaklement (elementTail)) { 

parseIntegerSchemaElement (element Id) ; 

eise ( 

throw new ParseException( 
String.format(*Argument: $c has invalid format: %s.*, 

elementId, elementTaili, 0); 


private void validateSchemaElementId(char elementid) throws ParseException ( 
if (!Character.isLetterielementId)) { 
throw new ParseException( 
"Bad character:' + elementld + "in Args format: " + schema, 0); 
} 
private void parseBooleanSchemaElement (char elementId) { 
booleanArgs.put(elementId, false); 
1 


private void parseIntegerSchemaElement(char elementId) ( 
intàrgs.put(elementid, 0); 


private void parseStringSchemaElement ichar elementId) { 
stringArgs.put (elementId, **); 


private boolean isStringSchemaElement (String elementTail) ( 
return elementTail.equals("*"); 


} 


private boolean isBooleanSchemaElement (String elementTail) { 
return elementTail.length() == 0; 


} 


private boolean isIntegerSchemaElement (String elementTail) ( 
return elementTail.equals(*$"); 
u 


Args: о rascunho 


197 


Listagem 14-8 (continuação) 
Args.java (primeiro rascunho) 


private boolean parseArguments() throws ArgsException ( 
for (currentargument = 0; currentArgument < args.length; currentArgument++) 


String arg = args[currentArgument] ; 
parseArgument (arg) ; 


return true; 
private void parseArgument (String arg) throws ArgsException { 


if (arg.startsWith(*-")) 
parseElements (arg) ; 


private void parseElements (String arg) throws ArgsException+{ 
for (int i = 1; 1 < arg.length(); i++) 
parseElement (arg.charAt (i)); 


} 


private void parseElement (char argChar) throws ArgsException { 
if (setArgument (argChar! j 
argsFound. add (argChar) ; 
else ( 
unexpectedArguments . add (argChar! ; 
errorCode = ErrorCode.UNEXPECTED ARGUMENT; 
valid - false; 


} 


private boolean setArgument (char argChar) throws ArgsExcepticn { 
if (isBooleanArg(argChar) ) 
secBooleanArg(argChar, true); 
else if (isStringArg!argChar]) 
setStringArg(argChar) ; 
eise if (isIntArg(argChar) } 
set IntArg(argChar} ; 
else 
return false; 


return true; 


private boolean isIntArg(char argChar) {return intArgs.containsKey (argChar) ;} 


private void setIntArgichar argChar) throws ArgsException { 
currentArgument++; 
String parameter = null; 
try { 

parameter = args[currentArgument]; 

intArgs.put (argChar, new Integer parameter) ); 

catch (ArrayIndexOutOfBoundsException ej { 

valid - false; 

errorArgumentId = argChar; 

errorCode = ErrorCode.MISSTNG INTEGER; 
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throw new ArgsException!); 

) catch (NumberFormatException e) [ 
valid - false; 
errorArgumentld = argChar; 
errorParameter - parameter; 
errorCode - ErrorCode.INVALID INTEGER; 
throw new ArgsException(); 

} 


} 


private void setStringàrgichar argChar) throws ArgsException { 
currentArgument++; 
try { 

stringArgs.put(argChar, args[currentArgument]); 

catch (ArrayIndexOutOfBoundsException e) ( 

valid = false; 

errorArgumentId = argChar; 

errorCode = ErrorCode.MISSING STRING; 

throw new ArgsException(); 


) 


private boolean isStringArg(char argChar) { 
return stringArgs.containsKey (argChar) ; 

} 

private void setBooleanàrg(char argChar, boolean value) { 
booleanàrgs.putíaraChar, lue); 

H 


private boolean isBooleanArgichar argChar) { 
return booleanàrgs.containsKey (argChar) ; 


public int cardinality() ( 
return argsFound.size(i; 
) 


public String usage(j { 
if (schema.length() > 0) 
return * + schema + "]"; 
else 
return ""; 


public String errorMessage() throws Exception { 
switch (errorCode) { 

case OK: 
throw new Exceptioni"TILT: Should not get here."!; 

Case UNEXPECTED ARGUMENT: 
return unexpectedArgumentMessage ( ) ; 

case MISSING STRING: 
return String.format('Could not find string parameter for -%с.", 

errorArgument Id) ; 
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case INVALID INTEGER: 


return String.format ("Argument -%c expects an integer but was '$s'.", 


errorArgumentid, errorParameter); 
case MISSING INTEGER: 
return String. format ("Could not find integer parameter for -$c.", 


errorArgumentid) ; 
} 


return **; 
} 


private String unexpectedArgumentMessage() ! 
StringBuffer message = new StringBuffer ("Argument (s) -*}; 
for (char c : unexpectedArguments) ( 
message.append(c) ; 


message.append(* unexpected." 


return message.toString(); 
j 


private boolean falselfNull (Boolean b) ( 
return b !- null && b; 
H 


private int zeroliNull (Integer i) { 
return i null 2.0: i; 
1 


private String blankIiNull(String s) ( 
return s == null ? ** 


public String getString(char ага) ( 
return blankIfNull(stringArgs.get (arg)); 
2 


public int getIntíchar arg) { 
return zerolftiull (intArgs.ger (arg) ); 
Н 
public boolean getBoolean(char arg! ( 
return falselfNull(booleanArgs.get (arg) ) ; 
) 


public boolean has(char arg) ( 
return argsFound.contains (arg) ; 


public boolean isValid() ( 
return valid; 


i 


private class ArgsException extends Exception { 
} 
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Espero que sua reação inicial a esse pedaço de código seja "Realmente estou feliz por ele não 
tê-lo deixado assim!”. Se você se sentir assim, então lembre-se de como as outras pessoas ficarão 
ao ler um código que você deixou num formato de “rascunho”. 

Na verdade, “rascunho” é provavelmente a coisa mais gentil que se possa falar desste código. 
Está claro que é um trabalho em progresso. Quantidade de instâncias de variáveis é assustadora, 
Strings estranhas, como “TILT”, "HashSets" e “TreeSets, e os blocos try. ..catch... 
catch ficam todas amontoadas. 

Eu não queria criar um código amontoado. De fato, eu estava tentando manter as coisas 
razoavelmente bem organizadas. Você provavelmente pode deduzir isso dos nomes que escolhi 
para as funções e as variáveis, e o fato de que mantive uma estrutura bruta. Mas, obviamente, 
me afastei do problema. 

A bagunça cresceu gradualmente. As versões anteriores não estavam tão bagunçadas assim. Por 
exemplo, a Listagem 14,9 mostra uma versão antiga na qual só funcionavam os parâmetros do 


tipo booleano. 


Listagem 14-9 
Args.java (Booleano apenas) 


package com.objeccmentor.utilities.getopts; 
import java.util.*; 


public class Args ( 
private String schema; 
private String[] aras; 
private boolean vi i 
Set<Character> unexpectedArguments = new TreeSet<Character>(); 
Map<Character, Boolean> booleanArgs = 
new HashMap«Character, Воо1еап>(); 
private int numberOfArguments = 0; 


public Args(String schema, String[] args) ( 
this.schema - schema; 
this.args = ага: 
valid = рагѕе(): 


} 


public boolean isValid(! { 
return valid; 


private boolean parse() ( 
if (schema.length(? 
return true; 
parseSchema i) ; 
parseArguments () ; 
return unexpectedArguments.sizei) 


0 && args.length 


private boolean parseSchema() ( 
for (String element : schema.spliti*,*)) { 
parseSchemaE] emen: (element) ; 


Args: о rascunho 


201 


Listagem 14-9 (continuação) 
Args.java (Booleano apenas) 


return true; 


) 


private void parseSchemaElement(String element) 
if telement.lengthi} == 1) ( 
parseBooleanSchemaElement (element); 
1 


1 
private void parseBooleanSchemaElement(String element) { 


'haracter.isbetter(c]) ( 
booleanArgs.putic, false); 


if 


} 


private boolean parseArgumentsi) { 
for (String arg : args) 
parseArgument (arg) ; 
return true; 
} 


private void parseArgument (String arg) { 
if (arg.startsWith("-")) 
parseElements (arg) ; 
) 


private void parseElemente (String arg) í 
for (int i = 1; i < arg.lengthi); i++ 
parseElement (arg.charAt (ij); 


private void parseElement (char argChar) ( 
if (isBoolean(argChar)) { 
numberOfArguments++; 
setBooleanArg(argChar, true! ; 
) else 
unexpectedarguments.add(argChar) ; 
j 


private void setBooleanArg(char araChar, boolean value) 
booleanArgs.put(argChar, value); 


private boolean isBoolean(char argChar) ( 
return booleanArgs.containsKey largChar); 
H 


public int cardinalityij ( 
, return numberOfArguments; 
public String usage) 
if (schema.length() > 0) 
return "-["+schema+"]"; 
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else 
return **; 
) 


public String errorMessage() ( 
if (unexpectedArguments.size() > 0) { 
return unexpectedArgumentMessage!) ; 
} else 
return 


private String unexpectedArgumentMessage() { 
StringBuffer message = new StringBufferi"Argumentis) -*): 
for (char c : unexpectedArguments) ( 
message.append (c); 


message.append(* unexpected. *); 


return message.toString(); 
public boolean getBoolean(char arg) į 
return booleanargs.get (arg); 


Embora você possa encontrar muitas formas de criticar esse código, ele não está tão ruim assim. 
Ele está compacto, simples e fácil de entender. Entretanto, dentro dele é fácil identificar as 
“sementes” que bagunçarão o código. Está bem claro como ele se tornará uma grande zona. 
Note que a bagunça futura possui apenas mais dois tipos de parâmetros do que estes: String e 
integer. Só essa adição tem um impacto negativo enorme no código. Ele o transformou de algo 
que seria razoavelmente passível de manutenção em algo confuso cheio de bugs. 

Inseri esses dois tipos de parâmetro de modo gradual. Primeiro, adicionei o parâmetro do tipo 
String, que resultou no seguinte: 


Listagem 14-10 
Args.java (Booleano e String) 


package com.objectmentor utilities.getopts; 


import java.text.ParseException; 


import java.util.*; 

public class args 1 
private String schema; 
private String[] args; 


private boolean valid - true; 
Set«Character» unexpectedArguments = new TreeSet<Character>(); 
private Map<Character, Boolean» booleanrgs = 

new HashMap<Character, Boolean>(); 
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Listagem 14-10 (continuação) 
Args.java (Booleano e String) 


private Map«Character, String» stringargs = 
new HashMap<Character, String»(); 
private Set«Character» argsFound = new HashSet<Character>(); 
private int currentArgument ; 
private char errorArgument = '\0'; 


enum ErrorCode | 
OK, MISSING STRING] 


private ErrorCode errorCode = ErrorCode.OK; 


public Args(String schema, String[] args) throws ParseException { 
this.schema - schema; 
this.args - args; 
valid = parse(): 


te boolean parsei) throws ParseException ( 

hema.length() == 0 && args.length == 9) 
return true; 

parseSchema) ; 

parseArguments () ; 

return valid; 


private boolean parseSchema() throws ParseException { 
for (String element : schema.spliti",*)) { 
if (element.length() > 0) { 
ing trimmedElement = element.trim(!; 
parseSchemaElement (trimmedElement ) ; 


) 


} 
return true; 
! 


private void parseSchemaElement (String element) throws ParseException { 
char elementid = element .charAt (0); 
String elementTail = element.substring{1); 
validateSchemaElementId (element Td) ; 
if (isBooleanSchemaElement (elementTail)) 
parseBooleanSchemaElement (element Id); 
else if (isStringSchemaElement (elementTaili) 
parseSrringSchemaElement (element Id) ; 


) 


private void validateSchemaElementId(char elementId) throws ParseException 
if (!Character.isLetter(elementIdi) { 
throw new ParseExceptioni 
"Bad character:* + elementid + "іп Args format: " + schema, 0); 


private void parseStringSchemaElement (char elementId) { 
stringArgs.put (element1d, **); 


t 


204 


Capítulo 14: Refinamento Sucessivo 


Listagem 14-10 (continuação) 
Args.java (Booleano e String] 


private boolean i 
return elementTail.equals(**"); 
} 


ringSchemaElement (String elementTail) { 


private boolean isBooleanSchemaElement (String elementTail) | 


return elementTaii.length() 
Р) 


private void parseBooleanSchemaElement (char elementId) į 


booleanArgs.put (elementId, false); 


private boolean parseArguments() { 


fcr (currentArgument = 0; currentArgument « args.length; currentArgument++) 


{ 
String arg = args |currentArgument] ; 
parseArgument (arg): 

} 

return true; 


} 


private void parseArgument (String arg) ( 
if targ.startsWith(*-*]) 
parseElements (arg! ; 


private void parseElements (String arg) { 
for (int i = i < arg.length(); i++) 
parseElement (arg.charAt (1)); 


n 


private void parseElement(char argChar! { 
if (setArgument (argChar) ) 
argsFound. add (argChar) ; 
else ( 
unexpectedArguments. add (arathar. 
valid = false; 
3 
H 


private boolean secArgument (char argChar) { 

boolean set = true; 

if (isBooleanlargChar!) 
setBooleanArg(argChar, true); 

else if (isString(argChar)) 
secStringArg(argChar, ""}; 

else 
set = false; 


return set; 
J 


private void setStringArg(char argChar, String s) 
currentArgument++; 
try ( 
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stringArgs.put (argChar, args [currentArgument)) ; 
catch (ArrayIndexOutOfBoundsException e! ( 
valid - false 
errorArgument = argChar; 
errorCode = ErrorCode. MISSING. STRING; 

i 
} 


private boolean isStrina(char агаСһаг) { 
return stringàrgs.containsKey (argChar) ; 
i 


private void setBooleanAra (char argChar, boolean value) { 
booleanArgs.put (argChar, value): 
} 


private boolean isBooleantchar argChar! | 
return bocleanArgs.containsk 


public int cardinalityi) { 
return argsFound.size(); 


) 


public String usage(! ( 
if (schema.length() » 0) 
return *-[* + schema + *]*; 
else 
return "*; 


) 


public String errcrMessage(! throws Exception ( 

if (unexpectedArguments,size() > 0) ( 

return unexpectedArgumentMessage |); 
} else 

switch (errorCode) { 

case MISSING_STRING: 
return String. format ("Could not find string parameter for -%с.*, 
errorArgument) ; 


case 0} 
throw new Exception (*TILT: Should not get here. 


return ""; 


) 


private String unexpectedArgumentMessage() { 
StringBuffer message = new StringBuffer(*Argument is) -"); 
ior ichar c : unexpectedArguments) { 
message.append(c! ; 
+ 
message.appendí* unexpected 


return message.toString(); 
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public boolean getBoolean(char arg) { 
return falseIiNul] (booleanArgs.get (arg) ) ; 
) 


private boolean falseIfNull(Boolean bj ( 
return b -- null ? false : b; 

} 

public String getString(char arg) { 
return blankIfNullistringArgs.get (arg) }; 


} 


private String blankIfNull (String s) ( 
return 8 null ? ** : s; 


j 


public boolean hasíchar arg) { 
return argsFound.contains (arg); 
public boolean isvalia() ( 
return valid; 
} 
) 


Você pode ver que as coisas começaram a fugir ao controle. Ainda não está horrível, mas a 
bagunça certamente está crescendo. É um amontoado, mas ainda não está tão grande assim. Isso 
ocorreu com a adição do parâmetro do tipo integer. 


Portanto, eu parei 


Eu tinha pelo menos mais dois tipos de parâmetros para adicionar, e eu poderia dizer que eles 
piorariam as coisas. Se eu forçasse a barra, provavelmente os faria funcionar também, mas 
deixaria um rastro de bagunça grande demais para consertar. Se a estrutura deste desse código 
algum dia for passível de manutenção, este é o momento para consertá-lo. 

Portanto, parei de adicionar novos recursos e comecei a refatorar. Como só adicionei os 
parámetros do tipo string е integer, eu saiba que cada tipo exigia um bloco de código novo 
em três locais principais. Primeiro. cada tipo requer uma forma de analisar a sintaxe de seu 
elemento de modo a selecionar o HashMap para aquele tipo. Depois, seria preciso passar cada 
tipo nas strings da linha de comando e convertê-lo para seu tipo verdadeiro. Por fim, cada tipo 
precisaria de um método get xxx de modo que pudesse ser retornado ao chamador já em seu 
tipo verdadeiro. 

Muitos tipos diferentes, todos com métodos similares —isso parece uma classe para mim. E, 
então, surgiu 0 ArgumentMarshaler. 


Incrementalismo 


Uma das melhores maneiras de arruinar um programa é fazer modificações excessivas em sua 
estrutura visando uma melhoria. Alguns programas jamais se recuperam de tais “melhorias”. O 
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problema é que é muito difícil fazer o programa funcionar como antes da “melhoria”. 

A fim de evitar isso, sigo o conceito do Desenvolvimento dirigido a testes (TDD, sigla em 
inglés). Uma das doutrinas centrais dessa abordagem é sempre manter o sistema operante. Em 
outras palavras, ao usar o TDD, não posso fazer alterações ao sistema que o danifiquem. Cada 
uma deve mantê-lo funcionando como antes. 

Para conseguir isso, precisei de uma coleção de testes automatizados que eu pudesse rodar quando 
desejasse e que verificasse se o comportamento do sistema continua inalterado. Para a classe 
Args, criei uma coleção de testes de unidade e de aceitação enquanto eu bagunçava o código. Os 
testes de unidade estão em Java e são gerenciados pelo JUnit. Os de aceitação são como páginas 
wiki no FitNesse. Eu poderia rodar esses testes quantas vezes quisesse, e, se passassem, eu ficaria 
confiante de que o sistema estava funcionando como eu especificara. 

Sendo assim, continuei e fiz muitas alterações minúsculas. Cada uma movia a estrutura do 
sistema em direção ao ArgumentMarshaler. E ainda assim, cada mudança mantinha o sistema 
funcionando. A primeira que fiz foi adicionar ao esqueleto do ArgumentMarshaller ao final da 
pilha amontoada de códigos (Listagem 14.11). 


Listing 14-11 
ArgumentMarshaller appended to Args.java 


private class ArgumentMarshaler { 
private boolean bcoleanValue - false; 


public void setBoolean(boolean value) ( 
booleanValue - value; 


} 


public boolean getBoolean!) {return booleanvalue;} 


private class BooleanArgumentMarshaler extends 
) 


jumentMarshaler ( 


private class StringArgumentMarshaler extends ArgumentMarshaler ( 
) 


private class IntegerArgumentMarshaler extends ArgumentMarshaler ( 
} 


Obviamente, isso não danificaria nada. Portanto, fiz a modificação mais simples que pude, uma 
que danificaria o minimo possivel. Troquei o HashMap dos parâmetros do tipo booleano para 
receber um ArgumentMarshaler. 


private Map<Character, ArgumentMarshaler> booleanArgs = 
new HashMap<Character, ArgumentMarshaler>(); 


Isso danificou algumas instruções, que rapidamente consertei. 
private void parseBooleanSchemaElement (char elementId) ( 


booleanArgs.put(elementId, new BooleanArgumentMarshaler()); 
) 
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private void setBooleanArg(char argChar, boolean value) ( 
booleanArgs.get(argChar).setBoolean(value); 


1 


public boolean getBoolean(char arg) { 
return falseIfNull(booleanArgs.get(arg).getBoolean()); 
› 


Note como essas mudanças estão exatamente nas áreas mencionadas anteriormente: o parse, o 
set е о get para o tipo do parâmetro. Infelizmente, por menor que tenha sido essa alteração, 
alguns testes começaram a falhar. Se olhar com atenção para о getBoolean, verá que se você 
o chamar com “у”, mas não há houver parâmetro y, booleanArgs.get (*y’) retornará null e a 
função lançará uma Nu 1PointerException. Usou-se a função falseTfNul1 para evitar que 
isso ocorresse, mas, com a mudança que fiz, ela se tornou irrelevante. 

O incrementalismo exige que eu conserte isso rapidamente antes de fazer qualquer outra alteração. 
De fato, a solução não foi muito difícil. Só tive de mover a verificação por null. Não era mais 
um booleano nu11 que eu deveria verificar, mas o ArgumentMarshaller. 

Primeiro, removi a chamada a falseI£Nu11 na função getBoolean. Ela não fazia mais nada 
agora, portanto a eliminei. Os testes ainda falhavam de certa forma, então eu estava certo de que 
não havia gerado novos erros. 


public boolean getBoolean(char arg) ( 
return booleanArgs.get(arg).getBoolean(); 
) 


Em seguida, divide dividi a função em duas linhas e coloquei 
o ArgumentMarshaller em sua própria variável chamada 
argumentMarshaller. Não me preocupara com o tamanho do nome; ele 
era redundante e bagunçava a função. Portanto o reduzi para am [N5]. 


public boolean getBoolean(char arg) { 
Args.ArgumentMarshaler am = booleanArgs.get(arg); 
return am.getBoolean(); 

) 


E, então, inseri a lógica de detecção de null. 


public boolean getBoolean(char arg) ( 
Args.ArgumentMarshaler am - booleanArgs.get(arg); 
return am !- null && am.getBoolean(); 


Parámetros do tipo string 


Adicionar parâmetros do tipo string é muito semelhante à adição de parâmetros booleanos. 
Eu tive de mudar o HashMap e fazer as funções parse, get e set funcionarem. Não há muitas 
surpresas depois, talvez pareça que eu esteja colocando toda a implementação de disponibilização 
(marshalling) na classe base ArgumentMarshal ler em vez de seus derivados. 


private Map<Character, ArgumentMarshaler> stringArgs = 
new HashMap<Character, ArgumentMarshaler>(); 
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private void parseStringSchemaElement(char elementId) ( 
stringArgs.put(elementId, new StringArgumentMarshaler(|)); 


) 


private void setStringArg(char argChar) throws ArgsException ( 
currentArgument++; 


ent]; 


) 


try ( 


stringArgs.get(argChar).setString(args[currentArgum 


) catch (ArrayIndexOutOfBoundsException e) ( 


valid - false; 

errorArgumentId = argChar; 

errorCode = ErrorCode.MISSING STRING; 
throw new ArgsException(); 


public String getString(char arg) ( 
Args.ArgumentMarshaler am = stringArgs.getiarg); 
return am == null ? " " : am.getString(); 


} 


private class ArgumentMarshaler { 
private boolean booleanvalue = false; 
private String stringValue; 


i 


public 


void setBoolean(boolean value) ( 
booleanValue - value; 


boolean getBoolean() ( 
return booleanValue; 


void tString(String s) { 
stringValue = s; 


String getString() { 
return stringValue == null ? " " : stringValue; 


Novamente, essas alterações foram feitas uma de cada vez e de tal forma que os testes estavam 
sempre funcionando. Quando um falhava. eu me certificava de fazê-lo passar com êxito antes de 
fazer a próxima mudanga. 
Mas, a esta altura, vocé já deve saber o que pretendo. Após eu colocar todo o comportamento doa 
disponibilização dentro da classe base ArgumentMarshaler, começarei a passá-lo hierarquia 
abaixo para os derivados. Isso me permitirá manter tudo operante enquanto eu modifico 
gradualmente a forma deste programa. 
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O próximo, e óbvio, passo foi mover a funcionalidade do parámetro do tipo int para 
ArgumentMarshaler. Novamente, nào há nada de novo aqui. 


private Map<Character, ArgumentMarshaler> intArgs = 
new HashMap<Character, ArgumentMarshaler>(); 
private void parseIntegerSchemaElement(char elementId) ( 
intArgs.put(elementId, new IntegerArgumentMarshaler()); 


H 

private void setIntArg(char argChar) throws ArgsException ( 
currentArgument++; 
String parameter = null; 
try ( 


parameter = args[currentArgument]; 
intArgs.get(argChar).setInteger(Integer. 
parseInt(parameter)); 

) catch (ArrayIndexOutOfBoundsException e) ( 
valid - false; 
errorArgumentId = argChar; 
errorCode = ErrorCode.MISSING INTEGER; 
throw new ArgsException(); 

) catch (NumberFormatException e) ( 
valid = false; 
errorArgumentId = argChar; 
errorParameter = parameter; 
errorCode = ErrorCode.INVALID INTEGER; 
throw new ArgsException(); 


) 


public int getInt(char arg) ( 
Args.ArgumentMarshaler am = intArgs.get(arg); 
return am == null ? 0 : am.getInteger(); 

) 


private class ArgumentMarshaler ( 
private boolean booleanValue - false; 
private String stringValue; 
private int integerValue; 


public void setBoolean(boolean value) ( 
booleanValue - value; 
H 


public boolean getBoolean() ( 
return booleanValue; 


) 


public void setString(String s) ( 
stringValue - S; 
) 
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public String getString() { 
return stringValue 


null ? ** : stringValue; 
} 


public void setInteger(int i) { 
integerValue = i; 
H 


public int getInteger() ( 
return integerValue; 
) 
) 


Após mover toda a disponibilização para ArgumentMarshaler, comecei a passar a 
funcionalidade para os derivados. O primeiro passo foi mover a função setBoolean para 
BooleanArgumentMarshaller e me certificar de que fosse chamada corretamente. Portanto, criei 
um método set abstrato. 


private abstract class ArgumentMarshaler { 
protected boolean booleanValue - false; 
private String stringValue; 
private int integerValue; 


public void setBoolean(boolean value) ( 


booleanValue - value; 


public boolean getBoolean() ( 
return booleanValue; 


public void setString(String s) ( 
stringValue = s; 


public String getString() { 
return stringValue == null ? "" : stringValue; 


public void setInteger(int i) { 
integerValue = i; 


public int getInteger() { 
return integerValue; 
Y 


public abstract void set(String s); 
) 


Então, implementei o método set em BooleanArgumentMarshaller. 
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private class BooleanArgumentMarshaler extends ArgumentMarshaler ( 
public void set(String s) { 
booleanValue = true; 


} 
} 


E, finalmente, substitui a chamada a setBoolean pela chamada ao set. 


private void setBooleanArg(char argChar, boolean value) { 
booleanArgs.get (argChar).set("true”); 
} 


Os testes ainda passavam. Como essa mudança causou a implementação do set 
em BooleanargumentMarshaler, removi o método setBoolean da classe base 
ArgumentMarshaler. 

Note que a função set abstrata recebe um parâmetro do tipo String, mas a implementação em 
BooleanArgumentMarshaller não o usa. Coloquei um parâmetro lá porque eu sabia que 
StringArgumentMarshaller e IntegerArgumentMarshaller о usariam. 

Depois, eu queria implementar o método get em BooleanArgumentMarshaler. Mas 
implementar funcóes get sempre fica ruim, pois o tipo retornado tem de ser um Object, e neste 
caso teria de ser declarado como um booleano. 


public boolean getBoolean(char arg) ( 
Args.ArgumentMarshaler am = booleanArgs.get(arg); 
return am !- null && (Boolean)am .get(); 

} 


Só para que isso compile, adicionei a função get a 
ArgumentMarshaler. 


private abstract class ArgumentMarshaler { 


public Object get() ( 
return null; 
} 
H 


A compilação ocorreu e, obviamente, os testes falharam. Fazé-los funcionarem 
novamente era simplesmente uma questão de tornar o get abstrato e implementá-lo em 
BooleanAgumentMarshaler. 


private abstract class ArgumentMarshaler ( 
protected boolean booleanValue - false; 


public abstract Object get(); 
} 


private class BooleanArgumentMarshaler extends ArgumentMarshaler { 
public void set (String s) { 
booleanValue = tru 
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public Object getí) ( 
return booleanValue; 
} 


1 


Mais uma vez, os testes passaram. Portanto, as implementações de get е set ficam em 
BooleanArgumentMarshaler! 

Isso me permitiu remover a função get Boolean antiga de ArgumentMarshaler, movera variável 
protegida booleanValue abaixo para BooleanArgumentMarshaler e torná-la privada. 

Fiz as mesmas alterações para os tipos string. Implementei set e get e exclui as funções nào 
mais utilizadas e movi as variáveis. 


private void setStringArg(char argChar) throws ArgsException ( 

currentArgument++; 
try ( 

stringArgs.get(argChar).set(args(currentArgument]); 
) catch (ArrayIndexOutOfBoundsException e) ( 

valid - false; 

errorArgumentId = argChar; 

errorCode - ErrorCode.MISSING STRING; 

throw new ArgsException(); 


) 


public String getString(char arg) { 
Args.ArgumentMarshaler am - stringArgs.get(arg); 
return am == null ? "" : (String) am.get(); 

} 


private abstract class ArgumentMarshaler ( 
private int integerValue; 


public void setInteger(int i) ( 
integerValue - i; 
} 


public int getInteger() ( 
return integerValue; 


} 


public abstract void set(String s); 
public abstract Object get(); 
) 


private class BooleanArgumentMarshaler extends ArgumentMarshaler ( 
private boolean booleanValue - false; 
public void set(String s) ( 
booleanValue - true; 
) 


public Object get() ( 
return booleanValue; 
} 
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) 


private class StringArgumentMarshaler extends ArgumentMarshaler ( 
private String stringValue = ""; 
public void set(String s) ( 
stringValue = s; 
) 


public Object get() ( 
return stringValue; 
) 
) 


private class IntegerArgumentMarshaler extends 
ArgumentMarshaler ( 
public void set(String s) ( 
) 


public Object get() ( 
return null; 
H 


Por fim, repeti o processo para os inteiros (integer). Só um pouco mais complicado, pois 
os inteiros precisam ser analisados sintaticamente, e esse processo pode lançar uma exceção. 


Mas o resultado fica melhor, pois toda a ação de NumberFormatException fica escondido em 
IntegerArgumentMarshaler. 


private boolean isIntArg(char argChar) (return intArgs 
containsKey(argChar);) 


private void setIntArg(char argChar) throws ArgsException { 

currentArgument++; 

String parameter = null; 

try { 
parameter = args[currentArgument]; 
intArgs.get(argChar).set (parameter); 

) catch (ArrayIndexOutOfBoundsException e) ( 
valid - false; 
errorArgumentId - argChar; 
errorCode - ErrorCode.MISSING INTEGER; 
throw new ArgsException(); 

) catch (ArgsException e) ( 
valid = false; 
errorArgumentId argChar; 
errorParameter - parameter; 


errorCode - ErrorCode.INVALID INTEGER; 
throw e; 


d 


private void setBooleanArg(char argChar) ( 
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try ( 
booleanArgs.get(argChar).set("*true"); 
) catch (ArgsException e) ( 
) 
} 


public int getInt(char arg) { 
Args.ArgumentMarshaler am = intArgs.get(arg); 
return am == null ? 0 : (Integer) am .get(); 

} 

private abstract class ArgumentMarshaler { 
public abstract void set(String s) throws ArgsException; 
public abstract Object get(); 

) 


private class IntegerArgumentMarshaler extends ArgumentMarshaler ( 
private int intValue = 0; 


public void set(String s) throws ArgsException { 
try í 
intValue - Integer.parseInt(s); 
) catch (NumberFormatException e) ( 
throw new ArgsException(); 
) 
} 


public Object get() { 
return intvalue; 


; 
+ 


É claro que os testes continuavam a passar. Depois, me livre dos três maps diferentes по início do 
algoritmo. Isso generalizou muito mais o sistema todo. Entretanto, não consegui me livrar dele 
apenas excluindo-os, pois isso danificaria o sistema. 

Em vez disso, adicionei um novo Map a ArgumentMarshaler e, então, um a um, mudei os 
métodos e o usei este novo Map no lugar dos três originais. 


public class Args ( 


private Map<Character, ArgumentMarshaler» booleanArgs = 
new HashMap<Character, ArgumentMarshaler»(); 

private Map«Character, ArgumentMarshaler» stringArgs - 
new HashMap<Character, ArgumentMarshaler»(); 

private Map<Character, ArgumentMarshaler» intArgs - 
new HashMap<Character, ArgumentMarshaler>(); 

private Map<Character, ArgumentMarshaler> marshalers = 
new HashMap<Character, ArgumentMarshaler>(); 


private void parseBooleanSchemaElement (char elementId) ( 
ArgumentMarshaler m = new BooleanArgumentMarshaler(); 
booleanArgs.put(elementId, m); 
marshalers.put(elementId, m); 
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1 


private void parseIntegerSchemaElement (char elementId) { 
ArgumentMarshaler m = new IntegerArgumentMarshaler(); 
intArgs.put (elementId, m); 
marshalers.put(elementId, m); 

› 


private void parseStringSchemaElement(char elementId) { 
ArgumentMarshaler m = new StringArgumentMarshaler(); 
stringArgs.put(elementId, m); 
marshalers.put(elementId, m| 


J 
É claro que todos os testes ainda passaram. Em seguida, modifiquei o isBooleanArg disso: 


private boolean isBooleanArg(char argChar) ( 
return booleanArgs.containsKey (argChar); 
H 


para isso: 


private boolean isBooleanArg(char argChar) ( 
ArgumentMarshaler m = marshalers.get(argChar); 
return m instanceof BooleanArgumentMarshaler; 


Os testes ainda passaram. Portanto, fiz a mesma mudança em isIntArg e isStringArg. 


private boolean isIntArg(char argChar) ( 
ArgumentMarshaler m = marshalers.get(argChar); 
return m instanceof IntegerArgumentMarshaler; 

) 

private boolean isStringArg(char argChar) ( 
ArgumentMarshaler m = marshalers.get(argChar); 
return m instanceof StringArgumentMarshaler; 

) 


Os testes ainda passaram. Portanto, eliminei todas as chamadas repetidas a marshalers.get: 


private boolean setArgument(char argChar) throws ArgsException ( 
ArgumentMarshaler m = marshalers.get(argChar); 
if (isBooleanArg(m)) 
setBooleanArg(argChar); 
else if (isStringArg(m)) 
setStringArg(argChar); 
else if (isIntArg(m)) 
setIntArg(argChar); 
else 
return false; 
return true; 
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private boolean isIntArg(ArgumentMarshaler m) { 
return m instanceof IntegerArgumentMarshaler; 
) 


private boolean isStringArg(ArgumentMarshaler m) ( 
return m instanceof StringArgumentMarshaler; 
) 


private boolean isBooleanArg(ArgumentMarshaler m) ( 
return m instanceof BooleanArgumentMarshaler; 
H 


Isso não fez nada de mais para os trés métodos i sxxxArg. Portanto, eu os encurtei: 


private boolean setArgument(char argChar) throws ArgsException ( 
ArgumentMarshaler m = marshalers.get(argChar); 
if (m instanceof BooleanArgumentMarshaler) 
setBooleanArg(argChar); 
else if (m instanceof StringArgumentMarshaler) 
setStringArg(argChar); 
else if (m instanceof IntegerArgumentMarshaler) 
setIntArg(argChar); 
else 
return false; 
return true; 
} 


Depois, comecei a usar os map do marshalers nas funções set, danificando o uso dos outros 
três maps. Comecei com os booleanos. 


private boolean setArgument (char argChar) throws ArgsException 


ArgumentMarshaler m = marshalers.get(argChar); 

if (m instanceof BooleanArgumentMarshaler) 
setBooleanArg(m); 

else if (m instanceof StringArgumentMarshaler) 
setStringArg(argChar); 

else if (m instanceof IntegerArgumentMarshaler) 
setIntArg(argChar); 

else 
return false; 

return true; 

} 


private void setBooleanArg(ArgumentMarshaler m) t 
try ( 
m.set(*true*); // was: booleanArgs.get(argChar). 
setí(*true"); 
) catch (ArgsException e) ( 
) 
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Os testes continuam passando, portanto, fiz o mesmo para strings e inteiros. Isso me permitiu 
integrar parte do código de gerenciamento de exceção à função setArgument. 


private boolean setArgument (char argChar) throws ArgsException ( 
ArgumentMarshaler m - marshalers.get(argChar); 
try { 
if (m instanceof BooleanArgumentMarshaler) 
setBooleanArg(m); 
else if (m instanceof StringArgumentMarshaler) 
setStringArg(m); 
else if (m instanceof IntegerArgumentMarshaler) 
setIntarg(m); 
else 
return false; 
) catch (ArgsException e) ( 
valid = false; 
errorArgumentId = argChar; 
throw e; 


) 
return true; 


} 


private void setIntArg(ArgumentMarshaler m) throws ArgsException { 
currentArgument++; 

String parameter = null; 

try { 
parameter = args[currentArgument]; 
m.set (parameter); 

} catch (ArrayIndexOutOfBoundsException e) { 
errorCode - ErrorCode.MISSING INTEGER; 
throw new ArgsException(); 

} catch (ArgsException e) { 

errorParameter - parameter; 
errorCode - ErrorCode.INVALID INTEGER; 
throw e; 


} 


private void setStringArg(ArgumentMarshaler m) throws ArgsException 
1 
currentArgument++; 
try ( 
m.set(args[currentArgument]); 
) catch (ArrayIndexOutOfBoundsException e) ( 
errorCode = ErrorCode.MISSING STRING; 
throw new ArgsException(); 


H 
Quase consegui remover os trés maps antigos. Primeiro, precisei alterar a função gec Boolean disso: 


public boolean getBoolean(char arg) ( 
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Args.ArgumentMarshaler am = booleanArgs.get(arg); 


return am !- null && (Boolean) am.get(); 
} 


para isso; 
public boolean getBoolean(char arg) ( 


Args.ArgumentMarshaler am - marshalers.get(arg); 
boolean b - false; 


try ( 
b = am !- null && (Boolean) am.get(); 
) catch (ClassCastException e) ( 
b - false; 
T 
return b; 


} 


Você deve ter se surpreendido com essa última alteração. Por que decidi usar de repente а 
ClassCastException? O motivo é que tenho uma série de testes de unidade c uma série 
separada de testes de aceitação escritos no FitNesse. Acabou que os testes do FitNesse garantiram 
que, se você chamasse a getBoolean em um parâmetro não booleano, você recebia falso. Mas 
os testes de unidade não. 

Até este momento, eu só havia rodado os testes de unidade”. 

Essa última alteração me permitiu remover outro uso do map booleano: 


private void parseBooleanSchemaElement (char elementId) ( 
ArgumentMarshaler m = new BooleanArgumentMarshaler(); 


marshalers.put(elementId, m); 
) 


E agora podemos excluir o map booleano. 


public class Args ( 


private Map<Character; ArgumentMarshaler» booleanArgs — 
new-HashMap<Character; ArgumentMarshater>(); 

private Map<Character, ArgumentMarshaler> stringArgs = 
new HashMap<Character, ArgumentMarshaler>(); 
private Map<Character, ArgumentMarshaler> intArgs = 
new HashMap<Character, ArgumentMarshaler>(); 
private Map<Character, ArgumentMarshaler» marshaler: 
new HashMap<Character, ArgumentMarshaler»(); 


Em seguida, migrei os parâmetros do tipo String e Integer da mesma maneira e fiz uma pequena 
Za nos booleanos. 


private void parseBooleanSchemaElement(char elementId) ( 
marshalers.put(elementId, new BooleanArgumentMarshaler()); 
) 


private void parseIntegerSchemaElement(char elementId) ( 
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marshalers.put(elementId, new IntegerArgumentMarshaler()); 


private void parseStringSchemaElement(char elementId) ( 
marshalers.put(elementId, new StringArgumentMarshaler()); 
) 


public String getString(char arg) ( 
Args.ArgumentMarshaler am - marshalers.get(arg); 
try { 
return am == null ? ™ : (String) am.get(); 
) catch (ClassCastException e) ( 
return ""; 
+ 


H 


public int getInt(char arg) ( 
Args.ArgumentMarshaler am - marshalers.get(arg); 
try ( 


return am == null ? 0 : (Integer) am.get(); 
) catch (Exception e) ( 
return 0; 
› 
d 


public class Args ( 


private-Map«Character, ArgumentMarshaler» stringArgs— 
new-HashMap-Character; ArgumentMarshaler-(); 
private-Map«Character, ArgumentMarshaler» intArgs = 
private Map«Character, ArgumentMarshaler» marshalers - 
new HashMap«Character, ArgumentMarshaler»(); 


Em seguida. encurtei os métodos parse porque eles não fazem mais muita coisa. 


private void parseSchemaElement(String element) throws 
ParseException ( 
char elementId = element.charAt(0); 
String elementTail = element .substring(1); 
validateSchemaElementId(elementId); 
if (isBooleanSchemaElement(elementTail)) 
marshalers.put(elementId, new BooleanArgumentMarshaler()); 
else if (isStringSchemaElement(elementTail)) 
marshalers.put(elementId, new StringArgumentMarshaler()); 
else if (isIntegerSchemaElement (elementTail)) { 
marshalers.put(elementId, new IntegerArgumentMarshaler()); 
) else ( 
throw new ParseException(String.format( 
“Parâmetro: %c possui formato inválido: $s.", elementId, 
elementTail), 0); 
) 
) 


Tudo bem, agora vejamos o todo novamente. A Listagem 14.12 mostra a forma atual da classe Args. 
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Listagem 14-12 
Args.java (Após primeira refatoração) 


package com.objectmentor.utilities.getopts; 


import java.text.ParseException; 
import java.util.*; 


public class àrgs { 
private String schema; 
private String[] args; 
private boolean valid - true; 
private Set«Character» unexpectedArguments = new TreeSet<Character>(); 
private Map<Character, ArgumentMarshaler» marshalers 
new HashMap<Character, ArgumentMarshaler>(); 
private Set<Character> argsFound = new HashSet<Character>!); 
private int currentArgument; 
private char errorArgumentld = '\0 
private String errorParameter = "TILT"; 
private ErrorCode errorCode = ErrorCode.0K; 


private enum Errorcode ( 
OK, MISSING STRING, MISSING INTEGER, INVALID INTEGER, UNEXPECTED ARGUMENT) 


public Args(String schema, String[] args) throws ParseException ( 
this.schema - schema; 
this.arga - args; 
valid = parse(); 


{ 


private boolean parsel} throws ParseException { 

if (schema.length() 0 && args.length 9) 

return tru 

parseSchema () ; 
try { 
parseArguments() ; 

) catch (ArgsException е) ( 


return valid; 
} 


private boolean parseSchema() throws ParseException 
for (String element : schema.spliti".")) { 
if (element.length() > 0) { 
String trimmedElement = element.trim(); 
parseSchemaElement (trimmedElement) ; 
) 
i 
return true; 


1 


private void parseSchemaElement (String element) throws FarseException { 
char elementid = element .charAt (0); 
string elementTail = element .substring(1); 
validateSchemaElement Id (element Id) ; 
if (isBooleanSchemaElement (elementTail)) 
marshalers.put (elementId, new BooleanArgumentMarshaler()); 
else if (isStringSchemaElement (elementTail)) 
marshalers.put (elementId, new StringargumentMarshalert)); 
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Listagem 14-12 (continuação) 
Args.java (Após primeira refatoração) 


else if lisIntegerSchemaElement (elementTail)) ( 
marshalers.put(elementId, new IntegerArgumentMarshalert)); 

) eise ( 
throw new ParseException (String. format ( 
"Argument: $c has invalid format: $s.', elementId, elementTail), 0); 
) 

1 


private void validateSchemaElementId(char elementId) throws ParseException { 
if (!Character.isLetter(elementId)) ( 
throw new ParseException( 
"Bad character:" + elementId + "іп Args format: " + schema, 0); 
1 


) 


private boolean isStringSchemaElement(String elementTail) ( 
return elementTail.equals("*"); 
H 


private boolean isBooleanSchemaElement(String elementTail) í 
return elementTail.length() == 0; 
} 


private boolean isIntegerSchemaElement (String elementTail) ( 
return elementTail.equals ("4"); 


) 


ivate boolean parseArguments() throws ArgsException ( 

for (currentargument=0; currentArgument<args. length: currentArgument++) { 
Str. s [currentArgument] ; 
parseArgument (arg) ; 


return true; 


private void parseArgument (String arg) throws ArgsException ( 
if (arg.startsWith(*-*)) 
parseElements (arg); 
} 


private void parseElements (String arg) throws ArgsException { 
for (int i = 1; i « arg.length(); i++) 
parseElement larg.charAt (i)); 
) 


private void parseElement (char argChar) throws ArasException | 
if {setArgument (argChar) ) 
argsFound. add (argChar) ; 
else { 
unexpectedArguments .add (argChar) ; 
errorCode - ErrorCode.UNEXPECTED ARGUMENT; 
valid - false; 


) 
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Listagem 14-12 (continuação) 
Args.java (Após primeira refatoração) 


private boolean setArgument (char argChar) throws ArgsException { 
ArgumentMarshaler m = marshalers.get (argChar) ; 
try { 
if (m instanceof BooleanArgumentMarshaler) 
setBooleanArg (m); 
else if tm instanceof StringArgumentMarshaler) 
ringarg (m); 
{ш instanceof IntegerArgumentMarshaler) 


return false; 
catch (ArgsException e) ( 
valid - false; 
errorArgumentld = argChar; 
throw e; 
} 


return true; 


private void setIntArg(ArgumentMarshaler т) throws ArgsException ( 
currentArgument++; 
String parameter = null; 
try { 
parameter = args[currentArgument]; 
m.set (parameter); 
catch (ArrayIndexOutOfBoundsException e) ( 
errorCode - ErrorCode.MISSING INTEGER; 
throw new ArgsException(); 
catch (ArasException e) ( 
errorParameter = parameter; 
errorCode = ErrorCode. INVALID. INTEGER; 
throw e; 


і 


) 


private void setStringArg (ArgumentMarshaler m) throws ArgsException { 

currentArgument ++; 

try í 

m.set args [currentArgument] ) ; 

indexOutOfBoundsException e) { 

errorCode - ErrorCode.MISSING STRING; 

throw new ArgsException() ; 
! 


} 


private void setBooleanArg(ArgumentMarshaler m) ( 
try { 
m.set ("true"); 
) catch (ArgsException e) ( 
T 


public int cardinality() ( 
return argsFound.size(); 
} 
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Listagem 14-12 (continuação) 
Args.java (Após primeira refatoração) 


public String usage() ( 
if (schema.length(} > 9) 
return *-[* + schema + "]*; 
else 
return **; 


} 


public String errorMessage() throws Exception 
switch (errorCode) { 
case О! 
thr-w new Exception(*TILT: Should not get here."); 
case UNTXPECTED ARGUMENT: 
return unexpectedArgumentMessage() ; 
case MISSING STRING: 
return String.format ("Could not find string parameter fòr -%с.", 
errorArgument 1d) ; 


case INVALID_INTEGER: 
return String. format ("Argument -łc expects an integer but was '$s'.", 
errorArgumentId, errorParameter} ; 
case MISSING_INTEGER: 
return String. format ("Could not find integer parameter for -%c.", 
errorArgument Id) ; 
} 


return ""; 
| 


private String unexpectedArgumentMessage() | 
StringBuffer message = new StringBuffer(*Argument(s) -*j; 
for (char c : unexpectedarguments) | 
message. append 


message.append(* unexpected. "); 


return message.toString(); 


} 


public boolean getBoolean (char arg) { 
Args.ArgumentMarshaler am = marshalers.get (arg); 
boolean b = false; 
try ( 
Б = am != null && (Boolean) am.get(); 
) catch (ClassCastExceprion e) { 
b = false; 
| 
return b; 
} 


public String getString(char arg) ( 
Args.ArgumentMarshaler am = marshalers.get iarg) ; 
try { 
return am == null т "" : (String) am.get (i; 
) catch (ClassCastException e) { 
return "*; 
) 
} 
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Listagem 14-12 (continuação) 
Args.java (Após primeira refatoração) 


public int getInt(char arg) ( 
Args.ArgumentMarshaler am = marshalers.get larg) ; 


try ( 

return am == null 2 0 : (Integer) am.get(); 
) catch (Exception e) { 

return 0; 


) 
) 


public boolean has (char arg) { 
return argsFound.contains arg); 
) 


public boolean isValid() ( 
return valid; 
) 


private class ArgsException extends Exception ( 
i 


private abstract class ArgumentMarshaler ( 
public abstract void set (String =) throws ArgsException; 
public abstract Object get(); 

1 


private class BooleanArgumentMarshaler extends ArgumentMarshaler ( 
private boolean booleanValue = false; 


public void set(String в) ( 
booleanvalue = true; 
› 


public Object get() ( 
return booleanvalue; 
) 


private class StringArgumentMarshaler extends ArgumentMarshaler { 


private String stringvalue = *"; 


public void setiString s) ( 
stringValue = 3; 


} 


public Object get() f 
return stringValue; 
) 
} 


private class IntegerArgumentMarshaler extends ArgumentMarshaler { 
private int intValue - 0; 


public void set(String s) throws ArgsException { 
try { 
intValue = Integer.parseInt (в); 
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Listagem 14-12 (continuação) 
Args.java (Após primeira refatoração) 


) catch (NumberFormatExceprion e! { 
throw new ArgsException(); 


public Object get() { 
urn intValue; 


Depois de todo esse trabalho. isso é um pouco frustrante. A estrutura ficou um pouco melhor, 
mas ainda temos todas aquelas variáveis no início; Ainda há uma estrutura case de tipos em 
setArgument; e todas aquelas funções set estão horríveis. Sem contar com todos os tratamentos 
de erros. Ainda temos muito trabalho pela frente. 

Eu realmente gostaria de me livrar daquele case de tipos em setArgument [G23]. Eu preferia 
ter nele apenas uma única chamada. a ArgumentMarshaler.set. Isso significa que preciso 
empurrar setIntArg, setStringArg e setBooleanArg hierarquia abaixo para os derivados 
de ArgumentMarshaler apropriados. Mas há um problema. 

Se observar setIntArg de perto, notará que ele usa duas instâncias de variáveis: args е 
currentArg. Para mover set IntArg para baixo até BooleanArgumentMarshaler, terei de 
passer passar ambas as variáveis como parâmetros da função. Isso suja o código [F1]. Prefiro 
passar um parámetro em vez de dois. Felizzlimente, ha uma solução simples. Podemos converter 
о array args em uma lista e passar um Iterator abaixo para as funções set. Levei dez passos no 
exemplo a seguir para passar todos os testes após cada passo. Mas só lhe mostrarei o resultado. 
Você deve ser capaz de descobrir o que era a maioria desses pequenos passos. 


public class Args ( 
private String schema; 
private Stringtl-args; 
private boolean valid = true; 
private Set<Character> unexpectedArguments = new 
TreeSet<Character>(); 
private Map<Character, ArgumentMarshaler> marshalers = 
new HashMap<Character, ArgumentMarshaler>(); 
private Set<Character> argsFound = new HashSet<Character>(); 
private Iterator«String» currentArgument; 
private char errorArgumentId = ‘\0’; 
private String errorParameter = “TILT”; 
private ErrorCode errorCode = ErrorCode.OK; 
private List«String» argsList; 
private enum ErrorCode ( 
OK, MISSING STRING, MISSING INTEGER, INVALID INTEGER, 
UNEXPECTED ARGUMENT) 


public Args(String schema, String[] args) throws ParseException 


this.schema - schema: 
argsList - Arrays.asList(args); 
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valid = parse(); 
) 


private boolean parse() throws ParseException ( 
if (schema.length() -- 0 && argsList.size() 
return true; 
parseSchema(); 
try ( 


parseArguments(); 
} catch (ArgsException e) { 
) 
return valid; 
) 


private boolean parseArguments() throws ArgsException ( 
for (currentArgument - argsList.iterator(); 
currentArgument.hasNext();) ( 
String arg = currentArgument.next(): 
parseArgument (arg); 
} 
return true; 


) 


private void setIntArg(ArgumentMarshaler m) throws ArgsException 


String parameter - null; 

try ( 
parameter = currentArgument .next(); 
m.set (parameter); 

) catch (NoSuchElementException e) ( 
errorCode = ErrorCode.MISSING INTEGER; 
throw new ArgsException(); 

) catch (ArgsException e) { 
errorParameter - parameter; 


errorCode - ErrorCode.INVALID INTEGER; 
throw e; 


} 


private void setStringArg(ArgumentMarshaler m) throws 
ArgsException ( 


try ( 
m.set(currentArgument.next()); 

) catch (NoSuchElementException e) ( 
errorCode - ErrorCode.MISSING STRING; 
throw new ArgsException(); 


) 
Essas foram simples modificações nas quais todos os testes passaram. Agora podemos começar a 


mover as funções set para os derivados apropriados. Primeiro, preciso fazer a seguinte alteração 
em setArgument: 
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private boolean setArgument(char argChar) throws ArgsException ( 
ArgumentMarshaler m = marshalers.get(argChar); 
if (m == null) 
return false; 
try ( 
if (m instanceof BooleanArgumentMarshaler) 
setBooleanArg(m); 
else if (m instanceof StringArgumentMarshaler) 
setStringArg(m); 
else if (m instanceof IntegerArgumentMarshaler) 
setIntArg(m); 
eise 


return faise; 

) catch (ArgsException e) ( 
valid - false: 
errorArgumentId = argChar; 
throw e; 

J 

return true; 


} 


Essa mudança é importante porque queremos eliminar completamente a cadeia if-else. 
Logo, precisamos retirar a condição de erro lá de dentro. 

Agora podemos começar a mover as funções set. A setBooleanArg é trivial, então 
trabalharemos nela primeiro. Nosso objetivo é alterá-la simplesmente para repassar para 
BooleanArgumentMarshaler. 


private boolean setArgument(char argChar) throws ArgsException { 
ArgumentMarshaler m = marshalers.get(argChar); 
if (m == null) 
return false; 
try { 
if (m instanceof BooleanArgumentMarshaler) 
setBooleanArg(m, currentArgument); 
else if (m instanceof StringArgumentMarshaler) 
setStringArg(m); 
else if (m instanceof IntegerArgumentMarshaler) 
setIntArg(m); 
) catch (ArgsException e) { 
valid - false; 
errorArgumentId - argChar; 
throw e; 
) 
return true; 
} 


private void setBooleanArg(ArgumentMarshaler m, 
Iterator«String» currentArgument) 
throws ArgsException ( 
try 


m.set(“true”); 


+ 
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Não acabamos de incluir aquele tratamento de exceção? É muito comum na refatoração inserir 
e remover as coisas novamente. A pequeneza dos passos e a necessidade de manter os testes 
funcionando significa que você move bastante as coisas. Refatorar é como resolver o cubo de 
Rubik. Há muitos passos pequenos necessários para alcançar um objetivo maior. Cada passo 
possibilita o próximo. 

Por que passamos aquele iterator quando setBooleanArg certamente não precisa dele? 
Porque setIntArg e setStringArg precisarão! E porque queremos implementar todas 
essas três funções através de um método abstrato em ArgumentMarshaller e passá-lo para 
setBooleanarg. Dessa forma, setBooleanArg agora não serve para nada. Se houvesse uma 
função set em ArgumentMarshaler. poderiamos chamá-la diretamente. Portanto, é hora de 
criá-la! O primeiro passo é adicionar o novo método abstrato a ArgumentMarshaler. 


private abstract class ArgumentMarshaler ( 
public abstract void set(Iterator«String» currentArgument) 
throws ArgsException; . 
public abstract void set(String s) throws ArgsException; 
public abstract Object get(); 
} 


É claro que isso separa todos os derivados. Portanto, vemos implementar o novo método em cada um. 


private class BooleanArgumentMarshaler extends ArgumentMarshaler ( 
private boolean booleanValue = false; 


public void set(Iterator<String> currentArgument) throws ArgsException ( 
booleanValue = true; 
} 
public void set(String s) 1 
booieanVaiue--—true; 
} 


public Object get() ( 
return booleanValue; 
} 
) 


private class StringArgumentMarshaler extends ArgumentMarshaler ( 
private String stringValue = "^; 


public void set(Iterator«String» currentArgument) throws 
ArgsException ( 
# 


public void set(String s) ( 
stringValue - s; 


} 


public Object get() { 
return stringValue; 
} 
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} 


private class IntegerArgumentMarshaler extends ArgumentMarshaler { 
private int intValue = 0; 


public void set(Iterator<String> currentArgument) throws 
ArgsException ( 
) 


public void set(String s) throws ArgsException ( 
try { 
intValue - Integer.parseInt(s); 
) catch (NumberFormatException e) ( 
throw new ArgsException(); 
) 
) 


public Object get() ( 
return intValue; 
} 


H 


E, agora, podemos eliminar setBooleanArg! 


private boolean setArgument(char argChar) throws ArgsException ( 
ArgumentMarshaler m - marshalers.get(argChar); 
if (m null) 
return false; 


try ( 
if (m instanceof BooleanArgumentMarshaler) 
m.set(currentArgument); 
else if (m instanceof StringArgumentMarshaler) 
setStringArg(m); 
else if (m instanceof IntegerArgumentMarshaler) 
setIntArg(m); 
) catch (ArgsException e) ( 
valid - false; 
errorArgumentId = argChar; 
throw e; 
) 
return true; 


Todos os testes passam e a função set é implementada para BooleanArgumentMarshaler! 
Agora podemos fazer o mesmo para Strings e Integers. 


private boolean setArgument(char argChar) throws ArgsException ( 
ArgumentMarshaler m = marshalers.get(argChar); 
if (m null) 
return false; 


try ( 
if (m instanceof BooleanArgumentMarshaler) 
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m.set(currentArgument); 

else if (m instanceof StringArgumentMarshaler) 
m.set(currentArgument); 

else if (m instanceof IntegerArgumentMarshaler) 
m.set(currentArgument); 

) catch (ArgsException e) ( 

valid = false; 

errorArgumentId = argChar; 

throw e; 


) 
return true; 
› 
private class StringArgumentMarshaler extends ArgumentMarshaler { 
private String stringValue = ""; 
public void set(Iterator«String» currentArgument) throws 
ArgsException ( 
try ( 
stringValue = currentArgument.next(); 
) catch (NoSuchElementException e) ( 
errorCode = ErrorCode.MISSING STRING; 
throw new ArgsException(); 


) 


public void set(String s) ( 
) 


public Object get() ( 
return stringValue; 
} 


} 


private class IntegerArgumentMarshaler extends ArgumentMarshaler { 
private int intvalue = 0; 
public void set(Iterator<String> currentArgument) throws 
ArgsException { 
String parameter = null; 
try í 
parameter = currentArgument.next(); 
set (parameter); 
) catch (NoSuchElementException e) { 
errorCode = ErrorCode.MISSING INTEGER; 
throw new ArgsException(); 
) catch (ArgsException e) ( 
errorParameter = parameter; 
errorCode = ErrorCode.INVALID INTEGER; 
throw e; 


) 


public void set(String s) throws ArgsException ( 
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try ( 
intValue = Integer.parseInt(s); 
} catch (NumberFormatException e) { 
throw new ArgsException(); 
) 
) 


public Object дес) ( 
return intValue; 


Ji 


E, agora o coup de grace: pode-se remover o caso do tipo! Touché! 


private boolean setArgument(char argChar) throws ArgsException 
ArgumentMarshaler m = marshalers.get(argChar); * 
if (m null) 
return false; 
try i 
m.set(currentArgument); 
return true; 
) catch (ArgsException e) ( 
valid - false; 
errorArgumentld = argChar; 
throw e; 


) 


Agora podemos nos livrar de algumas fungóes inüteis em IntegerArgumentMarshaler e 
limpá-la um pouco. 


private class IntegerArgumentMarshaler extends ArgumentMarshaler ( 
private int intValue - 0 
public void set(Iterator«String» currentArgument) throws 
ArgsException ( 

String parameter = null; 

try { 
parameter = currentArgument.next(); 
intValue = Integer.parseInt (parameter); 

) catch (NoSuchElementException e) ( 
errorCode = ErrorCode.MISSING INTEGER; 
throw new ArgsException(); 

) catch (NumberFormatException c) ( 
errorParameter - parameter; 
errorCode - ErrorCode.INVALID INTEGER; 
throw new ArgsException(); 


3 


i 
public Object get() ( 
return intValue; 


) 
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Também podemos transformar ArgumentMarshaler em uma interface. 


private interface ArgumentMarshaler ( 
void set(Iterator<String> currentArgument) throws ArgsException; 
Object get(); 

) 


Portanto, agora vejamos como fica fácil adicionar um novo tipo de 
parámetro a à nossa estrutura. São necessárias poucas mudanças, 
e elas devem ser isoladas. Primeiro, adicionamos um novo teste de 
caso para verificar se o parâmetro double funciona corretamente. 


public void testSimpleDoublePresent() throws Exception ( 
Args args = new Args("x##", new String[] ("-x","42.3"]); 
assertTrue(args.isValid()); 
assertEquals(1, args.cardinality()); 
assert True(args.has(‘x’)); 
assertEquals(42.3, args.getDouble('x'), .001); 

) 


Agora, limpamos o código de análise da sintaxe e adicionamos o ## para detectar o parámetro 
do tipo double. 


private void parseSchemaElement(String element) throws ParseException ( 
char elementId = element.charAt(0); 
String elementTail - element.substring(1); 
validateSchemaElementId(elementId); 


if (elementTail.length() == 0) 

marshalers.put(elementId, new BooleanArgumentMarshaler()); 
else if (elementTail.equals("*"}) 

marshalers.put(elementId, new StringArgumentMarshaler()); 
else if (elementTail.equals("#”)) 

marshalers.put(elementId, new IntegerArgumentMarshaler()); 
else if (elementTail.equals(“Ht”)) 

marshalers.put (elementId, new DoubleArgumentMarshaler()); 
else 

throw new ParseException(String.format( 
“Parâmetro: $c possui formato inválido: $s.", elementId, elementTail), 0); 


} 


Em seguida, criamos a classe DoubleArgumentMarshaler. 


private class DoubleArgumentMarshaler implements ArgumentMarshaler { 
private double doubleValue = 0; 
public void set(Iterator<String> currentArgument) throws 


234 Capítulo 14: Refinamento Sucessivo 


ра 


public Object get() ( 
return doubleValue; 
x 


) 
Isso nos forca a adicionar um novo ErrorCode. 


private enum ErrorCode ( 

OK, MISSING STRING, MISSING INTEGER, INVALID INTEGER, UNEXPECTED_ 
ARGUMENT, 
MISSING DOUBLE, INVALID DOUBLE) 


E precisamos de uma função getDouble. 


public double getDouble(char arg) ( 
Args.ArgumentMarshaler am = marshalers.get(arg); 
try í 
return am == null ? 0 : (Double) am.get(); 
) catch (Exception e) ( 
return 0.0; 
, 
) 


E todos os testes passaram! Nào houve problemas. Portanto, agora vamos nos certificar de que todo 
o processamento de erros funcione corretamente. No próximo caso de teste, um erro é declarado se 


uma string cujo valor não corresponda ao tipo esperado é passada em um parámetro ##. 


public void testInvalidDouble() throws Exception ( 
Args args = new Args("x##", new String[] (*-x*,“Forty two"); 
assertFalse(args.isValid()); 
assertEquals(0, args.cardinality()); 
assertFalse(args.has('x')); 
assertEquals(0, args.getInt('x')); 


assertEquals(*Parámetro -x espera um double mas recebeu 'Quarenta е 


Dois'.", 
args.errorMessage()); 


) 


public String errorMessage() throws Exception ( 
switch (errorCode) ( 
case OK: 
throw new Exception(*TILT: Não deve entrar aqui."); 
case UNEXPECTED ARGUMENT: 
return unexpectedArgumentMessage(); 
case MISSING STRING: 
return String.format(*Náo foi possível encontrar um 
parámetro string para -$c.", 


errorArgumentId); 
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case INVALID. INTEGER: 
return String.format (“Parâmetro -$c espera um integer 
mas recebeu 
"*s'.", errorArgumentId, errorParameter); 
case MISSING INTEGER: 
return String.format(“Não foi possível encontrar um 
parâmetro integer para -$c.*, 


errorArgumentId); 

case INVALID DOUBLE: 

return String.format(“Parâmetro -*c espera um double mas 
recebeu "'*s'.", 

errorArgumentId, errorParameter); 


case MISSING DOUBLE: 
return String.format("N&o foi possível encontrar um parámetro 
double para -*c.", errorArgumentId); 
) 
return "^; 
) 


O teste passa com éxito. O próximo garante que detectemos devidamente um parámetro double 
que está faltando. 


public void testMissingDouble() throws Exception ( 

Args args = new Args("xiHi", new String[]{"-x”}); 
assertFalse(args.isValid()); 

assertEquals(0, args.cardinality()); 

assertFalse(args.has('x')); 

assertEquals(0.0, args.getDouble('x'), 0.01); 

assertEquals("Náo foi possível encontrar um parámetro double para -x. 
args.errorMessage()); 

) 


O teste passa normalmente. Fizemos isso apenas por questão de finalização. 
O código de exceção está horrivel e não pertence à classe Args. Também estamos lançando a 
ParseException, que não cabe a nós. Portanto, vamos unir todas as exceções em uma única 
classe, ArgsException, e colocá-la em seu próprio módulo. 
public class ArgsException extends Exception ( 
private char errorArgumentId = ‘\0’; 
private String errorParameter = “TILT”; 
private ErrorCode errorCode = ErrorCode.OK; 
public ArgsException() () 


public ArgsException(String message) (super(message);) 
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public class Args ( 


private char errorArgumentId = “0º; 
private String errorParameter = “TILT; 
private ArgsException.ErrorCode errorCode = ArgsException.ErrorCode. 


private List<String> argsList; 


public Args(String schema, String[] args) throws ArgsException ( 
this.schema - schema; 
argsList = Arrays.asList(args); 


valid = parse(); 
} 


private boolean parse() throws ArgsException ( 
if (schema.length() == 0 && argsList.size() == 0) 
return true; 
parseSchema(); 


try { 

parseArguments(); 
} catch (ArgsException e) ( 
} 


return valid; 


) 
private boolean parseSchema() throws ArgsException ( 
) 
private void parseSchemaElement(String element) throws ArgsException 
else 
throw new ArgsException 
String.format ("Parâmetro: 


$c possui formato inválido: 
%з.", 


elementId,elementTail)); 


private void validateSchemaElementId(char elementId) throws 
ArgsException ( 
if (!Character.isLetter(elementId)) ( 
throw new ArgsException( 
"Caractere errado:" + elementId + "no 
formato d Args: " + schema); 


) 


private void parseElement(char argChar) throws ArgsException { 
if (setArgument(argChar)) 
argsFound.add(argChar); 
else ( 
unexpectedArguments.add(argChar); 
errorCode = ArgsException.ErrorCode.UNEXPECTED . 


valid - false; 
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private class StringArgumentMarshaler implements ArgumentMarshaler 
private String stringValue = “"; 


public void set(Iterator«String» currentArgument) throws 
ArgsException { 
try ( 
stringValue = currentArgument.next(); 
} catch (NoSuchElementException e) { 
errorCode = ArgsException.ErrorCode.MISSING | 
STRING; 
throw new ArgsException(); 


public Object geti) { 
return stringValue; 
H 
T 


private class IntegerArgumentMarshaler implements ArgumentMarshaler 
private int intValue = 0; 


public void set(Iterator«String» currentArgument) throws 
ArgsException ( 
String parameter - null; 
try 1i 
parameter = currentArgument.next(); 
intValue - Integer.parseInt(parameter); 
) catch (NoSuchElementException e) ( 
errorCode = ArgsException.ErrorCode.MISSING . 


INTEGER; 
throw new ArgsException(); 
} catch (NumberFormatException e) ( 
errorParameter - parameter; 
errorCode = ArgsException.ErrorCode.INVALID_ 
INTEGER; 


throw new ArgsException(); 


public Object get() { 
return intValue; 
} 


) 
private class DoubleArgumentMarshaler implements ArgumentMarshaler 
private double doubleValue = 0; 
public void set(Iterator«String» currentArgument) throws 
a m EC String parameter - null; 


try ( 
parameter = currentArgument.next(); 
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doubleValue = Double.parseDouble(parameter); 
) catch (NoSuchElementException e) ( 
errorCode - ArgsException.ErrorCode.MISSING | 


DOUBLE; 
throw new ArgsException(); 

) catch (NumberFormatException e) ( 
errorParameter - parameter; 
errorCode = ArgsException.ErrorCode.INVALID_ 

DOUBLE; 
throw new ArgsException(): 
J 
H 
public Object get() ( 
return doublevalue; 
) 
) 
) 


Isso é bom. Agora Args lança apenas a exceção ArgsException que, ao ser movida para seu 
próprio módulo, agora podemos retirar de Args os variados códigos de suporte a erros e colocar 
naquele módulo. Isso oferece um local óbvio e natural para colocar todo aquele código e ainda 
nos ajuda a limpar o módulo Args. 

Portanto, agora separamos completamente os códigos de exceção e de erro do módulo Args. 
(Veja da Listagem 14.13 à 14.16). Conseguimos isso apenas com pequenos 30 passos, fazendo 
com que os testes rodem entre cada um. 


Listagem 14-13 
ArgsTest.java 


package com.objectmentor.utilities.args; 


import junit.framework.TestCase; 


public class ArgsTest extends TestCase | 
public void testCreateWithNoSchemaOrArguments() throws Exception { 
Агав args = new Args(**, new String[0]); 
assertEquals(0, aras.cardinality()); 
} 


public void testWithtoSchemaPutWithOneargument() throws Exception ( 
try { 
new Args(**, new String[]({"-x"}); 
fail(); 
) catch (ArgsException e) ( 
assertEquals (ArgsException.ErrorCode.UNEXPECTED ARGUMENT, 
-getErrorCode()) ; 
assertEqualsi'x', e.getErrorArgumentId()); 
р 
) 


public void testWithNoSchemaButWithMultipleArguments() throws Exception ( 
try { 
new Args(**, new String[](*-x*, *- 
fail); 


AH 
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Listagem 14-13 (continuação) 
ArgsTest .java 


} catch (ArgsException e) ( 
assertEquals (ArgsException.ErrorCode.UNEXPECTED ARGUMENT, 
e.get£rrorCode(]); 
assertEquals('x', e.getErrorArgument Id()): 


public void testNonLetterSchema() throws Exception ( 
try i 
new Aras("*", new String[]{}!; 
fail("Args constructor should have thrown exception"); 
) catch (ArgsException e) ( 
assertEquals (ArgsExcept ion .ErrorCode. INVALID ARGUMENT NAME, 
e.getErrorCode()); 
assertEquals('*', e.getErrorAraumentId()); 
J 
1 


public void testInvalidArgumentFormat() throws Exception { 
try í 
new Arge("f-", new String[]()); 
faili'Args constructor should have throws exception"); 
catch (ArgsException e) ( 
assertEquals(ArgsException.ErrorCode.iNVALID FORMAT, e.getErrorCode()); 
assertEquals('f', e.getErrorArgumentId()); 


public void testSimpleBooleanPresenti) throws Exception ( 
Адз args = new Args("x", new String[]i"-x"]) ; 
assertEquals(l, args.cardinality!)]); 


assertEquals(true, args.getBoolean('x')); 
) 


public void testSimpleStringPresent () throws Exception ( 
Args args = new Args('x**, new String[]|*-x", "param")i; 
assertEquals(1, args.cardinality ()): 
assertTrue (args. has (x')] ; 
assertEquals("param", args.getString('x')); 

Ш 


public void testMissingStringArgument () throws Exception ( 
try 6 
new Args(*x**, new String[] (*-x*)) ; 
fail() 
atch (ArgsException e) { 
assertEquals (ArgsException.ErrorCode.MISSING STRING, e.getErrorcode()); 
assertEquals('x', e.getErrorArgumentId!)); 


public void testSpacesInFormat() throws Exception ( 
Args args = new Args("x, у", new String[](*-xy*]); 
assertEquals(2, args.cardinality()); 
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Listagem 14-13 (continuação) 
ArgsTest.java 


assertTrue (args.has('x')) ; 
assertTrue(args.has('y')); 


+ 


public void testSimpleIntPresent() throws Exception ( 
Args args = new Args(*x#", new Str: 
assertEquals(1, args.cardinality(] 
assertTrue(args.has('x')); 
assertEqualsi42, args.getInt('x')); 


public void testInvalidInteger() throws Exception ( 
ху | 


) 


public void testMissingInteger!) throws Exception { 


) 


public void testSimpleDoublePresent () throws Exception { 


) 


public void testInvalidDouble() throws Exception { 


public void testMissingDouble() throws Exception { 


Dio, "42")); 


new Args("x#", new String[]{"-x", "Forty two"}); 


fail(); 

catch (ArgsException e) | 
assertEqualsiArgsException.ErrorCode.INVALID INTEGER, e.getErrorCodei)); 
assertEquals('x', e.getErrorArgumentId()); 

assertEqualsi"Forty two", e.getErrorParameter()); 


try f 
new Args(*x#", new String[] ("=x"); 
fail; 
) catch (ArgsException e) { 
assertEquals (rgsException.ErrorCode.MISSING INTEGER, e.getErrorCodel]); 
assertEquals('x', e.getErrorArgumentId()); 


Args args = new Args(*x##", new String[](*-x", '42.3"]); 
assertEquals(1, args.cardinality()) 
assertTrue(args.has('x')); 

assertEquals(42.3, args.getDcuble('x'), .001); 


try { 
new Args("x##", new String[]{"-x", "Forty two"}); 
fail(); 
} catch (ArgsException e) ( 
assertEquals(ArgsException.ErrorCode.INVALID DOUBLE, e.getErrorCode(l); 
assertEquals('x', e.getErrorArgumentld(]]; 
assertEquals(*Forty two", e.getErrorParameter()); 
И 
} 


try ( 
new Args(*"x##", new String[](*-x*1); 
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Listagem 14-13 (continuação) 
ArgsTest.java 


new Args(*x##", new String[](*-x*, "Forty two'l!; 

failü; 

catch (ArgsException e) ( 

assertEquals ArgsException.ErrorCode.INVALID DOUBLE, e.getErrorCode(}); 
assertEquals('x', e.getErrorArgumentId()); 

assertEquals(*Forty two", e.getErrorParameter()); 

П 


} 
public void testMissingDoublei; throws Exception { 
try { 
new Args(*x##", new String[](*-x*]]; 
faili); 
| catch tArgsExceprion e) ( 
assertEquals (ArgsException. ErrorCode.MISSING DOUBLE, e.getErrorCode()); 
assertEquals('x', e.getErrorArgument Id()); 
) 
1 


Listagem 14-14 
ArgsExceptionTest . java 


public class ArgsExceptionTest extends TestCase | 
public void testUnexpectedMessage() throws Exception ( 
ArgsException e - 


new ArgsException(ArgsException.ErrorCode.UNEXPECTED ARGUMENT, 
'x', null); 
assertEquals ("Argument -x unexpected. *, e.errorMessage(]); 


} 


public void testMissingStringMessage() throws Exception { 
ArgsException e = new ArgsException(ArgsException.ErrorCode.MISSING STRING, 
*x', null); 
assertEquals(*Could not find string parameter for -х.", e.errorMessageí)); 


public void testInvalidIntegerMessage() throws Exception { 
ArgsException e - 
new ArgsException(ArgsException.ErrorCode.INVALID INTEGER, 
'х', "Forty two"); 
assertEquals ("Argument -x expects an integer but was ‘Forty two'.", 
e.errorMessage()) ; 


} 


public void testMissingIntegerMessage(} throws Exception | 
ArgsException e = 
new ArgsExcept ion (ArgsException.ErrorCode.MISSING INTEGER, 'x', null); 
assertEquals ("Could not find integer parameter for -х.", e.errorMessagei)); 


public void testinvalidDoubleMessage() throws Exception { 
ArgsException e = new ArgsException (ArgsException.ErrorCode. INVALID. DOUBLE, 
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Listagem 14-14 (continuação) 
ArgsExceptionTest . java 


'x', "Forty two"); 
assertEquals!*Argument -x expects a double but was ‘Forty two'.", 
e.errorMessage(!) ; 


public void testMissingDoubleMessagei) throws Exception { 
ArgsException e = new ArgsException(ArgsException.ErrorCode.MISSING, DOUBLE, 


"x', null); 
assertEqualsi"Could not find double parameter for -x.", e.errorMessage()); 


Listagem 14-15 
ArgsException.java 


public class ArgsException extends Exception { 
private char errorArgumentld = ':0'; 
private String errorParameter 
private ErrorCode errorCode - 


= “TILT; 
ErrorCode.OK; 


public ArgsException() {} 
public ArgsException(String message) (super (message) ;) 


public ArgsException(ErrorCode errorCode) { 
this.errorCode = errorCode; 
public ArgsException(ErrorCode errorCode, String errorParameter) 
this.errorCode - errorCode; 
this.errorParameter = errorParameter; 
) 


public ArgsException(ErrorCode errorCode, char errorArgumentId, 
String errorParameter! ( 
this.errorCode = errorCode; 
this.errorParameter - errorParameter; 
this.errorArgumentId = errorArgumentId; 
} 


public char getErrorArgumentId() ( 
return errorArgumentId: 
) 


public void setErrorArgumentId(char errorArgumentId) 
this.errorArgumentld = errorArgumentId; 
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Listagem 14-15 (continuação) 
ArgsException.java 


public void setErrorArgumentId(char errorArgumentId) ( 
this.errorArgumentld = errorArgumentld; 


} 
public String getErrorParameter() ( 
return errorParameter; 


void setErrorParameter (String errorParameter) { 
errorParameter = errorParameter; 


public ErrorCode getErrorCode() ( 
return errorCode; 
1 


public void setErrorCode(ErrorCode errerCode) ( 
this.errorCode - errorCode; 


public String errorMessagei) throws Exception { 
switch ierrorCode) ( 
case OF: 
throw new Exceprion( "TILT: 
case UNEXPECTED ARGUMENT: 
return String. format ("Argument -&c unexpected.", errorArgumentld); 
case MISSING STRING: 
return String. format ("Could not find string parameter for -%с.', 
errorArgument Id); 


Should not get here.*); 


case INVALID INTEGER: 


return String. formar ("Argument -$c expects an integer but was 'is'.", 


errorArgumentId, errorParameter) ; 
case MISSING INTEGER: 


return String. format ("Could not find integer parameter for -%с.", 


errorArgument Id); 
case INVALID DOUBLE: 


return String. format ("Argument -%c expects a double but was '$s'.", 


errorArgumentId, errorParameter) ; 


case MISSING DOUBLE: 
return String. format ("Could nor find double parameter for -&c.", 
errorArgument Id! ; 
) 
return **; 


) 


public enum ErrorCode { 
OK, INVALID FORMAT, UNEXPECTED ARGUMENT, INVALID ARGUMENT NAME, 
MISSING STRING, 

INTEGER, INVALID INTEGER, 

MISSING DOUBLE, INVALID DOUBLE) 
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Listagem 14-16 
Args.java 


public class Args { 
private String schema; 
private Map«Character, ArgumentMarshaler» marshalers - 
new HashMap<Character, ArgumentMarshaler>(); 
private Set«Character» arasFound = new HashSet<Character>(); 
private Iterator«String» currentArgument; 
private List«String» argsList; 


public Args(String schema, String[] args) throws ArgsException ( 
this.schema - schema; 
argsList = Arrays.asList (args); 
parse(); 


private void parse() throws ArgsException { 
parseSchema() ; 
parseArguments () ; 

} 


private boolean parseSchema() throws ArgsException { 
for (String element : schema.split(*,*i) { 
if (element.length() > 0) ( 
parseSchemaElement (element.trim(!); 


) 
return true; 


) 


private void parseSchemaElement(String element) throws ArgsException ( 
char elementId = element .charAt (0); 
String elementTail = element .substring(1:; 
validateSchemaElement Id (element Id) ; 
if (elementTail.length() == 0) 
marshalers.put (elementId, new BooleanArgumentMarshaler()!; 
else if (elementTail.equals("**)) 
marshalers.put (elementId, new StringArgumentMarshaler()]; 


else if (elementTail.equals("#")) 
marshalers.put (elementId, new IntegerArgumentMarshaler(!); 
else if (elementTail.equals("##")) 
marshalers.put (element Id, new DoubleArgumentMarshaler () ); 
else 
throw new ArgsException (ArgsException.ErrorCode. INVALID FORMAT, 
elementId, elementTail); 
} 


private void validateSchemaElementId(char elementld) throws ArgsException ( 
if (!Character.isLetter(elementId)) { 
throw new ArgsException(ArgsException.ErrorCode.INVALID ARGUMENT NAME, 
elementId, null); 
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Listagem 14-16 (continuação) 
Args.java 


private void parseArcuments() throws ArgsException ( 
for (currentArgument = argsList.iteratorí): currentArgument .hasNext ( 
String arg = currentArgument .next (); 
parseArgument (arg) ; 
} 


1 


private void parseArgument (String ara) throws Argsexception { 
if (arg.startsWith(*-")) 
parseElements (arg) ; 


} 


private void parseElements (String arg) throws ArgsException { 
for (int i = 1; i < arg.length(); i++) Р 


parseElement (arg.charAt (1)); 
} 


private void parseElement (char argChar) throws ArgsException { 
if (setArgument (argChar]) 
argsFound. add (argChar) ; 
else ( 
throw new ArgsException (ArgsExcept ion. ErrorCode. UNEXPECTED ARGUMENT, 
argChar, null); 


} 


private boolean setArgument (char argChar) throws ArgsException { 
ArgumentMarshaler m = marshalers.get {argChar) ; 
if im null] 
return false; 
try { 
m.set (currentArgument) ; 
return true; 
catch (ArgsException e) ( 
e.setErrorArgumentId (argChar) ; 
throw e; 


A maioria das mudanças da classe Args foiforam exclusões. Muito do código foi apenas 
removido de Args e colocado em ArgsException. Otimo. Também movemos todos os 
ArgumentMarshaller para seus próprios arquivos. Melhor ainda. 

Muitos dos bons projetos de software se resumem ao particionamento—criar locais apropriados 
para colocar diferentes tipos de código. Essa separação de preocupações torna o código muito 
mais simples para se manter e compreender. 

De interesse especial temos o método errorMessage de ArgsException. Obviamente, é 
uma violação ao SRP colocar a formatação da mensagem de erro em Args. Este deve apenas 
processar os parâmetros. e não o formato de tais mensagens. Entretanto, realmente faz sentido 
colocar o código da formatação das mensagens de erro em ArgsException? 

Francamente, é uma obrigação. Os usuários não gostam de ter que de criar eles mesmos as 
mensagens de erro fornecidas por ArgsException. Mas a conveniência de ter mensagens de 
erro prontas e já preparadas para você não é insignificante. 
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A esta altura já deve estar claro que estamos perto da solução final que surgiu no início deste 
capítulo. Deixarei como exercício para você as últimas modificações. 


Conclusão 


Isso não basta para que um código funcione. Um código que funcione. geralmente possui 
bastantes erros. Os programadores que se satisfazem só de em verem um código funcionando 
não estão se comportando de maneira profissional. Talvez temam que não tenham tempo para 
melhorar a estrutura e o modelo de seus códigos, mas eu discordo. Nada tem um efeito mais 
intenso e degradante em longo termo sobre um projeto de desenvolvimento do que um código 
ruim. É possível refazer cronogramas e redefinir requisitos ruins. 

Podem-se consertar as dinâmicas ruins de uma equipe. Mas um código ruim apodrece e degrada, 
tornando-se um peso que se leva a equipe consigo. Não me canso de ver equipes caírem num 
passo lentíssimo devido à pressa inicial que os levou a criar uma massa maligna de código que 
acabou selando seus destinos. 

É claro que se pode-se limpar um código ruim. Mas isso sai caro. Conforme o código degrada, os 
módulos se perpetuam uns para os outros, criando muitas dependéncias ocultas e intrincadas. 
Encontrar e remover dependéncias antigas é uma tarefa árdua e longa. Por outro lado, manter 
o código limpo é relativamente fácil. Se você fizer uma bagunça em um módulo pela manhã, é 
mais fácil limpá-lo pela tarde. Melhor ainda, se fez a zona a cinco minutos atrás, é muito mais 
fácil limpá-la agora mesmo. 

Sendo assim, a solução é constantemente manter seu código o mais limpo e simples possível. 
Jamais deixe que ele comece a se degradar. 


1. Recentemente reescrevi este modulo em Ruby e ele ficou com 1/7 do tamanho e com uma 
estrutura levemente melhor. 


2.A fim de evitar surpresas desse tipo mais tarde, adicionei um novo teste de unidade que invoca 
todos os testes do FitNesse. 


15 


Características Internas do JUnit 


O JUnit é um dos frameworks Java mais famosos de todos. Em relação a frameworks, ele 
é simples, preciso em definição e elegante na implementação. Mas como é o código? Neste 
capítulo, analisaremos um exemplo retirado do framework JUnit. 
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O framework JUnit 


O JUnit tem tido muitos autores, mas ele começou com Kent Beck e Eric Gamma dentro de um 
avião indo à Atlanta. Kent queria aprender Java; e Eric, sobre o framework Smalltalk de testes de 
Kent. “O que poderia ser mais natural para uma dupla de geeks num ambiente apertado do que 
abrirem seus notebooks e começarem a programar?”' Após três horas de programação em alta 
altitude, eles criaram os fundamentos básicos do JUnit. 

O módulo que veremos, o Compari sonCompactor, é a parte engenhosa do código que ajuda a 
identificar erros de comparação entre strings. Dadas duas strings diferentes. como ABCDE e ABXDE, 
o módulo exibirá a diferença através da produção de uma string como <. . .B[X]D.. .>. 

Eu poderia explicar mais, porém, os casos de teste fazem um trabalho melhor. Sendo assim, veja 
a Listagem 15.1 e você entenderá os requisitos deste módulo em detalhes. Durante o processo, 
analise a estrutura dos testes. Elas poderiam ser mais simples ou óbvias? 


Listagem 15-1 
ComparisonCompactorTest . java 


package junit.tests.framework; 
import junit. framework .ComparisonCompactor; 
import junit. framework. TestCase; 


public class ComparisonCompactorTest extends TestCase ( 


public void testMessagel) { 
string failure- new ComparisonCompactor(0, "b 
assertTrue(*a expected:«[b]» but was:«[c]»" 


*c*) .compa 
1s (failure}}; 


public void testStarrSame() ( 
ring failure- new ComparisonCompactor(1, "ba", "bc").compact (null); 
assertEquals|'expected:«b[a]» but was:<b(c]>", failure); 


П] 


public void testEndSame{) ( 
String failure= new ComparisonCompactoríl, "ab", *cb*).compact (null); 
assertEquals į "expected:<[a]b> but was:<[c]b>", lure); 

} 


public void testSame() { 
String failure- new ComparisonCompactorii, "ab", "ab").compact (null); 
assertEquals("expected:<ab> but was:«ab»*, failure): 

} 


public void testNoContextStartAndEndsame() ( 
String failure- new ComparisonCompactor(0, "abc", *adc") .compact (null); 
assertEquals (*expected:<... [b]...> but was:c...[d]...»", failure); 

) 


1, JUnit Pocket Guide, Kent Beck, O'Reilly, 2004, p. 43. (ainda sem tradução) 
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Listagem 15-1 (continuação) 
ComparisonCompactorTest . java 


public void testStartAndEndContext() { 
String failure- new ComparisonCompactor(1, "abc", "айс") .compact (null); 
assertEquals (*expected:«a[b]c» but was:«a[d]c»', failure); 


public void testStartAndEndContextWithEllipses|] ( 
String failure- 

new ComparisonCompactor (1, "abcde", "abíde").compact (null); 

sertEquals (*expected:«...bic]d...» but was:«...b[fld...»", failure); 


) 


public void testComparisonErrorStartSameComplete() ( 
String failure- new ComparisonCompactor(2, "ab", 'abc*).compact (null); 
assertEquals(*expected:<ab[]> but was:<ab[c]>", failure); 


) 


ompar isonErrorEndSameComplete() { 
new ComparisonCompactor (0, "be", *abc*) .compact (null); 
>”, failure); 


public void te: 
String failur: 
assertEquals("expected:<i]...> but was:«[a].. 


} 


public void testComparisonErrorEndSameCompleteContext() { 
String failure- new ComparisonCompactor(2, "bc", *abc").compact (null); 
assertEquals('expected:«[]bc» but was:<[a]bc>", failure); 


public void testComparisonErrorOverlapingMatches() [ 
String failure- new ComparisonCompactor(Ü, "abc", *abbc").compact (null); 
sertEquals (“expected:<...[1...> but was:«...[b]...»*, failure); 


) 


public void testComparisonErrorOverlapingMatchesContext() { 
String failure- new ComparisonCompactor(2, "abc", 'abbc").compact (null); 
assertEquals("expected:«ab[]c» but was:«ab[b]c»", failure); 

) 


public void testComparisonErrorOverlapingMatches2() { 

String failure- new ComparisonCompactor (0, "abedde*, 
*abede") „compact (null); 

assertEquals("expected:«...[d]...» but was:<...[] 


*, failure): 


} 


public void testComparisonErrorOverlapingMatches2Context() ( 
String failure- 
new ComparisonCompactor(2, "abcdde*, "abcde").compact (nuil); 
assertEquals('expected:«...cd[d]e» but was:<...cd[Je>", failure); 
i 


public void testComparisonErrorwithActualNull () { 
String failure- new ComparisonCompactori0, "a", null) compact (null); 
assertEquals(*expected:«a» but was:<null>", failurei; 

) 


public void testComparisonErrorWithActualNullContext() ( 
String failure- new ComparisonCompactor(2, "а", null) .compact (null); 
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Efetuei uma análise geral do código no ComparisonCompactor usando esses testes, que cobrem 
100% do código: cada linha, cada estrutura if e loop for. Isso me dá um alto grau de confiança de 
que o código funciona e de respeito pela habilidade de seus autores. 

O código do ComparisonCompactor está na Listagem 15.2. Passe um momento analisando-o. 
Penso que você o achará bem particionado, razoavelmente expressivo e de estrutura simples. 
Quando você terminar, entenderemos juntos os detalhes. 


Listing 15-2 
ComparisonCompactor.java (Original) 


package junit. framework; 


public class ComparisonCompactor ( 


private static final String ELLIPSIS = * 
private static final String DELTA_END 
private static final String DELTA_START 


its 


private int fContextLength; 
private String fExpected: 
String fActual; 
private int fPrefix: 
private int fSuffix; 


public ComparisonCompactor(int contextLenath, 
String expected, 
String actual) ( 
fContextLength = contextLength; 
fExpected = expected; 
factual = actual; 


public String compact (String message) ( 


if (fExpected null || factual == null || areStringsEqual()) 
return Assert. format (message, fExpected, factual); 

findCommonPrefix(): 

findCommonsuffix(!; 


String expected = compactString (fExpected) ; 
ring actual = compactString (factual): 
return Assert. format (message, expected, actual); 


private String compactString(String source) ( 
String result - DELTA START « 
source.substring(fPrefix, source.length!) - 
fSuffix + 1) + DELTA END; 
if (fPrefix > 0) 
result = computeCommonPrefix() + result; 
if (fSuffix > 0) 
result = result + computeCommonSuffixi); 
return result; 
} 


private void findCommonPrefix() ( 
fPrefix = 0; 
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Listing 15-2 
ComparisonCompactor.java (Original) 


int end = Math.min(fExpected.length(), factual. length()); 


for (; fPrefix < end; fPrefix+) [ 
if (fExpected.charAt (fPrefix) != fActual.charAt (fPrefix)) 
break; 


nSuffix() ( 
fExpected.length() - 1; 
factual.length() - 1; 


private void findComm 
int expectedSu! 
int actualSuff. 


for i; 
actualSuffix »- fPrefix && expectedSuffix »- fPrefix; 
actualSuffix--, expectedSuffix--) { . 
if (fExpected.charAt (expectedSuf fix) fActual.charAt lactualSu£fix!) 
break; 
П 
fsuffix = fExpected.length() - expectedSuffix; 


) 


private String computeCommonPrefix!) ( 
return (fPre > fContextLength ELLIPSIS : 
fexpecred.subsrring (Math.max (0, fPrefix - fContextLength), 

fPrefix); 


) 


private String computeCommonSuffix() ( 
int end = Math.min(fExpected.length() - fSuffix + 1 + fContextLength, 
fExpected.length()); 
return fExpected. substring (fExpected.length() - fSuffix + 1, end) + 
ifExpected.length() - fSuffix + 1 < fExpected.length() - 
fContextLength ? ELLIPSIS : * 


) 


Talvez você tenha algumas críticas em relação a este módulo. Há expressões muito extensas 


e uns estranhos +15 е por aí vai. Mas, de modo geral, este módulo está muito bom. Afinal de 
contas, ele deveria estar como na Listagem 15.3. 


Listagem 15-3 
ComparisonCompator.java (sem refatoração) 


package junit.tramework; 


public class ComparisonCompactor { 
private int ctxt; 
private String sl; 
private String s2; 
private int pfx; 
private int sfx; 


public ComparisonCompactor (int ctxt, String sl, String 52) ( 
this.ctxt - ctxt; 
this.sl - sl; 
this.s2 - s2; 
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Listagem 15-3 
ComparisonCompator.java (sem refatoração) 


1 


public String compact (String msg) { 


if (sl == null null |i sl.equals(s2)) 
return Assert, format (msg, sl, s2); 
pix = 0; 
for i; pfx < Math.min(sl.length(), s2.length()); рЁх++} ( 
if (si.charAt(pfx) !- s2.charAtipfx)) 
break; 
} 
int sfxl = sl.length() - 1; 


int sfx2 = s2.length() - 1; 

for (; sfx2 >= pix && sfxl 

if (sl.charat (sfxl) 
break; 


pix; sfx2--. sfxl--) ( 
charat isfx2) ) 


) 

Sfx - sl.lengthi) - sfxl; 

String cmpl = compactStringisi): 
String cmp2 - compactString(s2); 
return Assert.format(msg, cmpl, cmp: 


private String compacrString (String s) { 
String result - 
*[" + s.substring(pfx, s.lengthii - sfx + 1) + "]*; 
if (pfx » 0) 
result = (pfx > ctxt ? *...* : "*) + 
sl.substring(Math.max(0, pfx - ctxt), pfx) + result; 


if (six » 0) [ 
int end = Math.min(sl.length() - sfx + 1 + ctxt, sl.length()); 
result = result + (sl.substring(sl.length() - sfx + 1, end) + 
(sl.length() - sfx + 1 < sl.length() - ctxt ? "...” : **)); 
} 
return result; 
) 


Mesmo que os autores tenham deixado este módulo num formato muito bom, a Regra de 
Escoteiro” nos diz que devemos deixá-lo mais limpo do que como você o encontrou. Portanto, 
como podemos melhorar o código original na Listagem 15.2? 

Primeiro, nào deve se preocupar com o prefixo £ nas variáveis membro [N6]. Os ambientes de 
hoje em dia tornam esse tipo de escopo redundante. Sendo assim, eliminemos todos os £. 


private int contextLength; 
private String expected; 
private String actual; 
private int prefix; 
private int suffix; 


al ento ace do a a Ene 
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Depois, temos uma estrutura condicional não encapsulada no início da função compact. [628]. 


public String compact(String message) { 
if (expected == null || actual == null || areStringsEqual()) 
return Assert.format(message, expected, actual); 
findCommonPrefix(); 
findCommonSuffix(); 
String expected = compactString(this.expected); 
String actual = compactString(this.actual); 
return Assert.format (message, expected, actual); 


} 


Devemos encapsular este if para deixar clara nossa intenção. Portanto, criemos um método 
que a explique. 


public String compact(String message) ( 
if (shouldNotCompact()) 
return Assert.format(message, expected, actual); 
findCommonPrefix(); 
findCommonSuffix(); 
String expected = compactString(this.expected); 
String actual = compactString(this.actual); 


return Assert.format(message, expected, actual); 
) 


private boolean shouldNotCompact() ( 


return expected == null || actual == null || areStringsEqual(); 
+ 


Não ligo muito para a notação this.expected e this.actual na função compact. Isso ocorreu quando 
alteramos o nome de fExpected para expected. Por que há variáveis nesta função que possuem 
os mesmos nomes das variáveis membro? Elas não representam outra coisa [N4]? Devemos 
desambigüizar os nomes. 


String compactExpected = compactString (expected); 
String compactActual = compactString(actual); 


É um pouco mais dificil entender negativas do que afirmativas [G29]. Portanto, vamos inverter 
aquela estrutura if. 


public String compact(String message) ( 
if (canBeCompacted()) ( 
findCommonPrefix(); 
findCommonSuffix(); 
String compactExpected = compactString(expected); 
String compactActual = compactString(actual); 
return Assert.format(message, compactExpected, 
compactActual); 
} else { 
return Assert.format(message, expected, actual); 
) 
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} 
private boolean canBeCompacted() ( 

return expected != null && actual 1= null && !areStringsEqual(); 
) 


O nome da função está estranho [N7]. Embora ela realmente compacte as strings, ela 
talvez não o faça se canBeCompacted retornar false, Portanto, nomear essa função como 
compact esconde o efeito colateral da verificação de erro. Note também que, além das strings 
compactadas, a função retorna uma mensagem formatada. Dessa forma, o nome da função 
deveria ser formatCompactedCompari son. Assim fica muito melhor quando lido juntamente 
com o parâmetro da função. 


public String formatCompactedComparison(String message) ( 


O corpo da estrutura if é onde ocorre a compactação real das strings. Deveriamos extrair isso 
para um método chamado compactExpectedAndActual. Entretanto, queremos que a função 
formatCompactedComparison faça toda a formatação. A função compact... não deve fazer 
nada além da compactação [G30]. Portanto, vamos dividi-la assim: 


private String compactExpected; 
private String compactActual; 


public String formatCompactedComparison(String message) ( 
if (canBeCompacted()) ( 
compactExpectedAndActual(); 
return Assert.format(message, compactExpected, 
compactActual); 
) else ( 
return Assert.format(message, expected, actual); 
} 


3 


private void compactExpectedAndActual() ( 
findCommonPrefix(); 
findCommonSuffix(); 
compactExpected = compactString(expected); 
compactActual = compactString(actual); 

} 


Note que isso nos força a transformar compactExpected e compactActual em variáveis- 
membro. Não gosto da forma de que as duas últimas linhas da nova função retorna as 
variáveis, mas duas primeiras não retornam. Elas não estão usando convenções consistentes 
[G11]. Portanto, devemos alterar findCommonPrefix e findCommonSuffix para retornar os 
valores do prefixo e do sufixo. 


private void compactExpectedAndActual() ( 
prefixIndex = findCommonPrefix(); 


suffixIndex = findCommonSuffix(); 
compactExpected = compactString(expected); 
compactActual = compactString(actual); 

} 


private int findCommonPrefix() { 
int prefixIndex = 0; 
int end = Math.min(expected.length(), actual.length()); 
for (; prefixIndex < end; prefixIndex++) { 
if (expected.charAt (prefixIndex) 
charAt (prefixIndex)) 
break; 


actual. 


} 
return prefixIndex; 
} 


private int findCommonSuffix() ( 


int expectedSuffix = expected.length() - 1; 
int actualSuffix = actual.length() - 1; 
for (; actualSuffix >= prefixIndex && expectedSuffix >= 
prefixIndex; 
actualsuffix--, expectedSuffix--) ( 


if (expected.charAt(expectedSuffix) actual. 
charat (actualSuffix)) 
break; 
) 
return expected.length() - expectedSuffix; 


H 
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Também deveríamos tornar os nomes das variáveis-membro um pouco mais precisos [N1]: 


apesar de tudo, ambas são índices. 


Uma análise cuidadosa de findCommonSuffix expõe um acoplamento temporário escondido 
[G31]; ele depende do fato de prefixIndex ser calculado por findCommonPrefix. Se chamassem 
essas duas funções fora de ordem, a sessão de depuração depois ficaria difícil. Portanto, para expor 
esse acoplamento temporário, vamos fazer com que findCommonSuffix receba prefixIndex 


como um parâmetro. 


private void compactExpectedandactual() ( 
prefixIndex = findCommonPrefix(); 
suffixIndex = findCommonSuffix(prefixIndex); 
compactExpected = compactString(expected); 
compactActual = compactString(actual); 


private int findCommonSuffix(int prefixIndex) ( 


int expectedSuffix - expected.length() - 1; 

int actualSuffx - actual.length() - 1; 

for (; actualSuffix >= prefixIndex && expectedSuffix >= 
prefixIndex; 


actualSuffix--, expectedSuffix 
if (expected.charAt(expectedSuffix) 


t 


actual. 
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charAt(actualSuffix)) 
break; 
3 
return expected.length() - expectedSuffix; 
) 


Não estou satisfeito com isso. A passagem de prefixIndex ficou um pouco arbitrária [G32]. 
Ela serve para estabelecer a ordenação, mas não explica essa necessidade. Outro programador 
talvez desfaca o que acabamos de fazer por não haver indicação de que o parámetro é realmente 
necessário. Portanto, tentemos de outra maneira. 


private void compactExpectedAndActual() ( 
findComronPrefixAndSuffix (); 
compactExpected = compactString(expected); 


compactActual = compactString(actual); 
} 


private void findCommonPrefixAndSuffix() ( 


findCommonPrefix(); 
int expectedSuffixk = expected.length() - 1; 
int actualSuffix = actual.length() - 1; 
for (; 
actualSuffix >= prefixIndex && expectedSuffix >= 
prefixIndex; 
actualSuffix--, expectedSuffix-- 
J -$ 
if (expected.charAt(expectedSuffix) != actual. 
charAt(actualsuffix)) 
break; 
} 
suffixIndex = expected.length() - expectedSuffix; 


} 


private void findCommonPrefix() { 
prefixIndex = 0; 
int end = Math.minlexpected.length(), actual.length()); 
for (; prefixIndex < end; prefixIndex++) 
if (expected.charAt(prefixIndex) !- actual. 
charAt(prefixIndex)) 
break; 
) 


Colocamos findCommonPrefix e findCommonsuffix como estavam antes, mudando o nome de 
findCommonSuffix para findCommonPrefixandsuffix e fazendo-a chamar findCommonPrefix 
antes de qualquer outra coisa. Isso estabelece a natureza temporária das duas funções de 
uma maneira muito mais expressiva do que a solução anterior. E também indicar como 
findCommonPrefixandSuffix é horrível. Vamos limpá-la agora. 


private void findCommonPrefixAndSuffix() ( 
findCommonPrefix(); 
int suffixLength = 1; 
for (; !suffixOverlapsPrefix(suffixLength); suffixLength++) { 
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if (charFromEnd(expected, suffixLength) 
charFromEnd(actual, suffixLength)) 
break; 


} 
suffixIndex = suffixLength; 
} 


private char charFromEnd(String s, int i) ( 
return s.charAt(s.length()-i);) 


private boolean suffixOverlapsPrefix(int suffixLength) ( 
return actual.length() - suffixLength < prefixLength || 
expected.length() - suffixLength < prefixLength; 

} 


Assim ficou muito melhor, pois mostra que suffixIndex é o comprimento (Length) do sufixo 
e que não está bem nomeado. O mesmo vale para prefixIndex, embora neste caso “índice” 
(Index) e “comprimento” (Length) sejam sinônimos. O problema é que a variável suffixIndex 
não começa com zero, mas por 1, e, portanto, não é um comprimento real. Esse também é o 
motivo pelo qual existem todos aqueles 1+s em computeCommonSuffix [G33]. Sendo assim, 
vamos consertar isso. 

O resultado está na Listagem 15.4. 


Listagem 15-4 
ComparisonCompactor.java (temporário) 


public class ComparisonCompactor { 


private void findCommonPrefixAndSuffix() { 
findCommonPrefix(); 
suffixLength = 0; 
for (; !suffixOverlapsPrefix(suffixLength); suffixbength++) ( 
if (charFromEnd (expected, suffixLength) != 
charFromEndíactual, suffixLength) ) 
break; 
1 
} 


private char charFromEnd(String s, int i) { 
return s.charatts.lengrh() - i - 1); 
! 


private boolean suffixoverlapsPrefix(int suffixLength) { 
return actual. length(i - suffixLength <= prefixLenath || 
expected. length() - suffixLength «s prefixLength; 


private String compactString(String source) { 
String result = 
DELTA_START + 
source.substring(prefixLength, source.length() - suffixLength) + 
DELTA_END; 
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Listagem 15-4 (continuação) 
ComparisonCompactor.java (temporário) 
DELTA END; 
if (prefixLength > 0! 
result = computeCommonPrefix() + result; 


if (suffixLength > 0) 
res lt + computeCommonSuffix(); 
return result; 


private String computeCommonSuffixi) { 
int end = Math.min(expected.lengthi) - suffixLength + 
contextLength, expected.length() 
l; 
return 
expected.substring(expected.length() - suffixLength, end) + 
(expected. length() - suffixLength < 
expected. length(! - contextLength ? 
ELLIPSIS : **]); 


Substituimos os «1s em computeCommonSuffix por um -1 em charFromEnd, onde faz 
mais sentido, e dois operadores <= em suffixOverlapsPrefix, onde também fazem mais 
sentido. Isso nos permitiu alterar о nome de suffixIndex para suffixLength, aumentando 
consideravelmente a legibilidade do código. 

Porém, há um problema. Enquanto eu eliminava os +15, percebi a seguinte linha em 
compactString: 


if (suffxLength > 0) 


Observe-a na Listagem 15.4. Pela lógica, como agora suffixLength está uma unidade menor do 
que anteriormente, eu deveria alterar o operador > para >=. Mas isso não faz sentido. Agora faz! 
Isso significa que antes não fazia sentido e que provavelmente era um bug. 

Bem, não um bug. Após análise mais detalhada, vemos que agora a estrutura if evita que um 
sufixo de comprimento zero seja anexado. Antes de fazermos a alteração, a estrutura if não era 
funcional, pois suffixIndex jamais poderia ser menor do que um. 

Isso levanta a questão sobre ambas as estruturas if em compact String! Parece que poderiam 
ser eliminadas. Portanto, vamos colocá-las como comentários e rodar os testes. Eles passaram! 
Sendo assim, vamos reestruturar compact String para eliminar as estruturas if irrelevantes е 
tornar a função mais simples. 


private String compactString(String source) ( 
return 
computeCommonPrefix() 4 
DELTA START + 
source.substring(prefixLength, source.length() - 
suffixLength) + 
DELTA END + 
computeCommonSuffix(); 
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Assim está muito melhor! Agora vemos que a função compactString está simplesmente 
unindo os fragmentos. Provavelmente, podemos tornar isso ainda mais claro. De fato, há várias 
e pequenas limpezas que poderíamos fazer. Mas em vez de lhe arrastar pelas modificações finais, 
mostrarei logo o resultado na Listagem 15.5. 


Listagem 15-5 
ComparisonCompactor.java (final) 


package junit. framework; 


public class ComparisonCompactor { 


private static final String ELLIPSIS = * 
private stat String DELTA END - i 
private stat String DELTA START = "[*; 


private int contextLength; 
private String expected; 
private String actual; 
private int prefixLenath; 
privare int suffixLength; 


public ComparisonCompactor ( 
int contextLength, String expected, String actual 
) 
this.contextLength = contextLength; 
this.expected = expected; 
this.actual = actual; 


public String ZormatCompactedComparison(Sstring message) [ 
String compactExpected = expected; 
String compactActual = actual; 
if (shouldBeCompacted()) { 
findCommonPrefixAndSuffix(); 
compactExpected = compact (expected); 
compactActual = compact (actual); 
) 
return Assert.format(message, compactExpected, compactActual); 
} 


private boolean shouldBeCompacted() { 
return !shouldNotBeCompacted() ; 
) 


private boolean shouldNotBeCompacted() { 
return expected == null || 
actual == null || 
expected.equals (actual): 


} 


private void findCommonPrefixAndSuffix|) ( 
findCommonPrefix(}; 
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Listagem 15-5 (continuação) 
ComparisonCompactor. java (final) 


suffixLength = 0; 
for (; 'suffixOverlapsPrefix(); suffixLength++) į 
if (charFromEná (expected, suffixLength) != 
charFromEnd (actual, suffixLength) 
) 


break; 


} 


private char charFromEnd(String s, int i 
return s.charAt(s.length(} - i - 1); 


private boolean suffixoverlapsPrefix() ( 
return actual.length(! - suffixLength <= prefixLenath || 
expected.length() - suffixLength <= prefixLength; 


private vcid findCommonPrefix() | 
prefixLength 
int end = Math.min (expected. length(), actual. length()); 
for (; prefixLength « end; prefixLength++) 
if (expected.charAt (prefixLength) !- actual.charAt (prefixLength) ) 
break; 


D 


private String compact (String s) ( 
return new ngBuilder i) 

-append(startingEllipsis ()) 
-append(startinoContexti!) 
.append(DELTA STAR 
-append(deltais)] 
„append (DELTA END) 
„append (endingContext í) ) 
„append endingEllipsis()) 
-toString(!; 


} 


private String startingEllipsis() { 
return prefixLength > contextLength ? ELLIPSIS : *'; 


private String startingContexti) ( 
int contextStart = Math.max(0, prefixLength - contextLength]; 
int contextEnd - prefixLength; 
return expected.substring(contextStarr, contextEnd); 

} 


private String delta(String s) { 
int deltaStart = prefixLength; 
int deltaEnd length() - suffixLength; 
return s.substring(deltaStart, deltaEnd) ; 
[ 
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Listagem 15-5 (continuação) 
ComparisonCompactor.java (final) 


private String endingContext () 
int contextStart = expected.length() - suffixLength; 
int contextEnd 
Math.min(contextStart + contextLength, expected.lengthi)); 
return expected. substring(contextStart, contextEnd); 


private String endingEllipsisi) { 
return isuffixLength > contextLenath ? ELLIPSIS : **]); 


Ficou realmente belo. O módulo está separado em um grupo de funções de análise e em um de 
síntese, E estão topologicamente organizadas de modo que a declaração de cada uma aparece 
logo após seu uso. Todas as funções de análise aparecem primeiro, e as de síntese por último. 
Se olhar com atenção, verá que reverti diversas das decisões que eu havia feito 
anteriormente neste capítulo. Por exemplo. coloquei de volta alguns métodos extraídos em 
formatCompactedComparison e alterei o sentido da expressão shouldNotBeCompacted. 

Isso é típico. Geralmente, uma refatoração leva à outra, que leva ao desfazimento da primeira. 
Refatorar é um processo iterativo cheio de tentativas e erros, convergindo inevitavelmente em 
algo que consideramos digno de um profissional. 


Conclusão 


E também cumprimos a Regra de Escoteiro. Deixamos este módulo um pouco mais limpo do 
que como o encontramos. Não que já não estivesse limpo. Seus autores fizeram um trabalho 
excelente com ele. 

Mas nenhum módulo está imune a um aperfeiçoamento, e cada um de nós tem o dever de deixar 
o código um pouco melhor do que como o encontramos. 

Esta página foi deixada intencionalmente em branco 
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Refatorando o SerialDate 


Se você for ao site http://www.jfree.org/jcommon/index.php, encontrará a biblioteca 
JCommon, dentro da qual há um pacote chamado org.jfree.date, que possui uma classe 
chamada SerialDate. Iremos explorar essa classe. 

David Gilbert é o criador da serialDate. Obviamente, cle é um programador competente е 
experiente. Como veremos, ele exibe um nível considerável de profissionalismo e disciplina dentro 
do código. Para todos os efeitos, esse é um “bom código”, E eu irei desmembrá-lo em partes. 
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Não possuo más intenções aqui. Nem acho que eu seja tão melhor do que o David que, de alguma 
forma, eu teria o direito de julgar seu código. De fato, se visse alguns de meus códigos, estou 
certo de que você encontraria várias coisas para criticar. 

Não, também não é uma questão de arrogância ou maldade. O que pretendo fazer aqui nada mais 
é do que uma revisão profissional. Algo com a qual todos nós deveríamos nos sentir confortáveis 
em fazer. E algo que deveríamos receber bem quando fizessem conosco. É só através de críticas 
como essas que aprenderemos. Os médicos fazem isso. Os pilotos também fazem. Os advogados 
também. E nós programadores precisamos aprender a fazer também. 

E mais uma coisa sobre David Gilbert: ele é muito mais do que um bom programador. 

David teve a coragem e a boa vontade de oferecer de graça seu código à comunidade em geral. 
Ele o colocou à disposição para que todos vissem, usassem e analisassem. Isso foi um bem feito! 
SerialDate (Listagem B.1, página 349) é uma classe que representa uma data em Java. Por que 
ter uma classe que represente uma data quando o Java já possui a java .util.Date ea java. 
util.Calendar, dentre outras? O autor criou essa classe em resposta a um incômodo que eu 
mesmo costumo sentir. O comentário em seu Javadoc de abertura (linha 67) explica bem isso. 
Poderíamos deduzir a intenção do autor, mas eu certamente já tive de lidar com essa questão e. 
então, sou grato a essa classe que trata de datas ao invés de horas. 


Primeiro, faça-a funcionar 


Há alguns testes de unidade numa classe chamada SerialDateTests (Listagem B.2, página 
366). Todos os testes passam. Infelizmente, uma rápida análise deles mostra que não testam tudo 
[T1]. Por exemplo, efetuar uma busca “Encontrar Tarefas” no método MonthCodeToQuarter 
(linha 334) indica que ele não é usado [F4]. Logo, os testes de unidade não o testam. 

Então, rodei o Clover para ver o que os testes de unidade cobriam e não cobriam. O Clover 
informou que os testes de unidades só executavam 91 das 185 instruções na SerialDate 
(~50%) [T2]. O mapa do que era testado parecia uma colcha de retalhos, com grandes buracos 
de código não executado amontoados ao longo de toda a classe. 

Meu objetivo era entender completamente с também refatorar essa classe. Eu não poderia fazer 
isso sem um teste de maior cobertura. Portanto, criei minha própria coleção de testes de unidade 
completamente independente (Listagem B.4, página 374) 

Ao olhar esses testes, você verá que muitos foram colocados como comentários. 

Esses testes falharam. Eles representam o comportamento que eu acho que a SerialDate 
deveria ter. Dessa forma, conforme refatoro a SerialDate, farei também com que esses 
testes passem com êxito. 

Mesmo com alguns dos testes colocados como comentário, o Clover informa que os novos testes 
de unidade executam 170 (92%) das 185 instruções executáveis. Isso é muito bom, e acho que 
poderemos aumentar ainda mais esse número. 

Os primeiros poucos testes postos como comentários (linhas 23-63) são um pouco de prepotência 
de minha parte. O programa não foi projetado para passar nesses testes, mas o comportamento 
parece óbvio [G2] para mim. 

Não estou certo por que o método testWeekdayCodeToString foi criado, mas como ele está 
lá, parece óbvio que ele não deve diferir letras maiúsculas de minúsculas. Criar esses testes foi 
simples [T3]. Fazê-los passar foi mais simples ainda; apenas alterei as linhas 259 e 263 para 
usarem equalsIgnoreCase. 
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Coloquei os testes nas linhas 32 e 45 como comentários porque não está claro para mim se as 
abreviações “tues” (Tuesday, terça-feira em inglês) e “thurs” (Thursday, quinta-feira em inglês) 
devem ser suportadas. 

Os testes nas linhas 153 e 154 falham. Obviamente, eles deveriam mesmo [G2]. Podemos 
facilmente consertá-los e, também, os testes das linhas 163 a 213, fazendo as seguintes 
modificações à função stringToMonthCode. 


457 || (result > 12)) { 

458 0; i < monthNames.length; i++) [ 
459 alsIgnoreCase(shortMonthNames[i]}) ( 
460 ult = 1 +1: 

461 break; 

462 

463 (s.equalsIgnoreCase(monthNames[i])) { 
464 result = і + 1; 

165 break; 

466 } 

467 ) 

168 i 


Otestecolocadocomocomentárionalinha3 | 8expdeumbugnométodoget Fol lowingDayOfWeek 
(linha 672). A data 25 de dezembro de 2004 caiu num sábado. E o sábado seguinte em 1º de 
janeiro de 2005. Entretanto, quando efetuamos o teste, vemos que getFollowingDayOfWeek 
retorna 25 de dezembro como o sábado seguinte a 25 de dezembro. Isso está claramente errado 
G3], [T1]. Vimos o problema na linha 685, que é um típico erro de condição de limite [TS]. 
Deveria estar escrito assim: 


685 if (baseDOW >= targetWeekday) { 


É interessante notar que essa função foi o alvo de um conserto anterior. O histórico de alterações 
(linha 43) mostra que os “bugs” em getPreviousDayOfWeek, getFollowingDayOfWeek е 
getNearestDayOfWeek [T6] foram consertados. 

O teste de unidade testGetNearestDayOfWeek (linha 329), que testa o método 
getNearestDayOfWeek (linha 705), não rodou por muito tempo e nào foi completo como 
está configurado para ser. Adicionei muitos casos de teste ao método, pois nem todos os meus 
iniciais passaram [T6]. Você pode notar o padrão de falhas ao verificar quais casos de teste 
estão como comentários [T7]. 

Isso mostra que o algoritmo falha se o dia mais próximo estiver no futuro. Obviamente, há um 
tipo de erro de condição de limite [T5]. 

O padrão do que o teste cobre informado pelo Clover também é interessante [T8]. A linha 719 
nunca é executada! Isso significa que a estrutura if na linha 718 é sempre falsa. De fato, basta 
olhar o código para ver que isso é verdade. A variável adjust é sempre negativa e, portanto, não 
pode ser maior ou igual a 4. Sendo assim, este algoritmo está errado. 

O algoritmo correto é disponibilizado abaixo: 
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if (adjust 
adjust - 


return SerialDate.addDays|adjust, base); 


Por fim, podem-se fazer os testes na linha 417 e 429 obterem êxito simplesmente lançando uma 
IllegalArgumentException ao invés de uma string de erro a partir de weekInMonthToString 
erelativeToString. 

Com essas alteragóes, todos os teste de unidade passam, e creio eu que agora a SerialDate 
funcione. Portanto, está na hora de torná-la "certa". 


Entáo, torne-a certa 


Iremos abordar a SerialDate de cima para baixo, aperfeiçoando-a no caminho. Embora 
você não veja esse processo, passarei todos os teste de unidade do JCommon, incluindo o meu 
melhorado para a SerialDate, após cada alteração que eu fizer. Portanto, pode ter certeza de que 
cada mudança que você vir aqui funciona com todos os testes do JCommon. 

Começando pela linha 1, vemos uma grande quantidade de comentários sobre licença, direitos 
autorais, criadores e histórico de alterações. Reconheço que é preciso tratar de certos assuntos 
legais. Sendo assim. os direitos autorais e as informações sobre a licença devem permanecer. Por 
outro lado, o histórico de alterações é um resquício da década de 1960, e deve ser excluído [C1]. 
Poderia-se reduzir a lista de importações (import) na linha 61 usando java .text .* e java. 
util.*. [1] 

Não gostei da formatação HTML no Javadoc (linha 67), pois o que me preocupa é ter um arquivo 
fonte com mais de uma linguagem contida nele. E ele possui quatro: Java, português, Javadoc 
e html [G1]. Com tantas linguagens assim, fica difícil manter tudo em ordem. Por exemplo, a 
boa posição das linhas 71 e 72 ficam perdidas quando o Javadoc é criado, e, mesmo assim, quer 
deseja ver <ul> e <1i> no código-fonte? Uma boa estratégia seria simplesmente envolver todo 
o comentário com <pre> de modo que a formatação visível no código-fonte seja preservada 
dentro do Javadoc'. 

A linha 86 éa declaração da classe. Por que essa classe se chama SerialDate? Qual о significado 
de “serial”? Seria por que a classe é derivada de Serializable? Parece pouco provável. 

Não vou deixar você tentando adivinhar. Eu sei o porquê (pelo menos acho que sei) da palavra 
"serial". A dica está nas constantes SERIAL LOWER BOUND e SERIAL UPPER BOUND 
nas linhas 98 e 101. Uma dica ainda melhor está no comentário que começa na linha 830. A 
classe se chama SerialDate por ser implementada usando-se um “serial number” (número de 
série, em português). que é o número de dias desde 30 de dezembro de 1899. 

Tenho dois problemas com isso. Primeiro, o termo “serial number” não está correto. Isso pode 
soar como uma crítica, mas a representação está mais para uma medida do que um número de 
série. O termo “serial number" tem mais a ver com a identificação de produtos do que com datas. 
Portanto, não acho este nome descritivo [N1]. Um termo mais explicativo seria “ordinal”. 

O segundo problema é mais significativo. O nome Serial Date implica uma implementação. 


1. Uma solução ainda melhor seria fazer o Javadoc apresentar todos os comentários de forma pré-formatada, de modo que tivessem о mesmo formato no código 


Primeiro, faça-a funcionar 267 


Essa classe é abstrata, logo não há necessidade indicar coisa alguma sobre a implementação, a qual, 
na verdade, há uma boa razão para ser ocultada. Sendo assim, acho que esse nome esteja no nível 
errado de [N2]. Na minha opinião, o nome da classe deveria ser simplesmente Date. 
Infelizmente, já existem muitas classes na biblioteca Java chamadas de Date. Portanto, essa, 
provavelmente, não é o melhor nome. Como essa classe é sobre dias ao invés de horas, pensei 
em chamá-la de Day (dia em inglês), mas também se usa demasiadamente esse nome em outros 
locais. No final, optei por DayDate (DiaData) como a melhor opção. 

A partir de agora, usarei o termo DayDate. Mas espero que se lembre de que nas listagens as 
quais você vir, DayDate representará SerialDate. 

Entendo o porquê de DayDate herdar de Comparable e Serializable. Mas cla herda de 
MonthConstants? Esta classe (Listagem B.3, página 372) é um bando de constantes estáticas 
finais que definem os meses. Herdar dessas classes com constantes é um velho truque usado pelos 
programadores Java de modo que não precisassem usar expressões como MonthConstants.January 
— mas isso é uma péssima idéia [J2]. AMonthConstants deveria ser realmente um enum. 


public abstract class DayDate implements Comparable, 
Serializable ( 
public static enum Month ( 
JANUARY (1), 
FEBRUARY (2) , 
МАВСН (3), 
APRIL(4), 
MAY(5), 
JUNE (6), 
JULY (7), 
AUGUST(B), 
SEFTEMBER (2) , 
ОСТОВЕК (101, 
NOVEMBER (11) , 
DECEMBER (12); 


Month(int index) ( 
this.index = index; 


= 
„Б. 


ic static Month maketint monthindex) | 
r (Month m : Month.values()) { 
if (m.index monthIndex) 


return m; 


throw new IllegalargumentException(“Invalid month index * + monthIndex) ; 


) 
public final int index; 


Alterar a MonthConstants para este enum exige algumas alterações na classe DayDate е para 
todos os usuários. Levei uma hora para fazer todas as modificações. Entretanto, qualquer função 
costumava pegar um int para um mês, agora pega um enum Month. Isso significa que podemos 
nos livrar do método isva1idMonthCode (linha 326) e de toda verificação de erro no código 
dos Month, como aquela em monthCodeToQuarter (linha 356) [G5]. 

Em seguida, temos a linha 91, serial VersionUID — variável usada para controlar o "serializador". 
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Se a alterarmos, então qualquer DayDate criado com uma versão antiga do software não será 
mais legível e produzirá uma InvalidClassException. Se você não declarar a variável 
serialVersionUID, o compilador gerará automaticamente uma para você, e ela será diferente toda 
vez que você alterar o módulo. Sei que todos os documentos recomendam controlar manualmente 
essa variável, mas me parece que o controle automático de serialização é bem mais seguro [G4]. 
Apesar de tudo. eu prefiro depurar uma 1nvalidClassException ao comportamento estranho 
que surgiria caso си me esquecesse de alterar о serialversionUID. Sendo assim, vou excluir 
a variável — pelo menos por agora’. 

Acho o comentário da linha 93 redundante. Eles só servem para passar mentiras e informações 
erradas [C2]. Portanto. vou me livrar de todo esse tipo de comentários. 

Os comentários das linhas 97 e 100 falam sobre os números de série (serial numbers) que 
mencionei anteriormente [C1]. As variáveis que eles representam são as datas mais antigas e 
atuais possíveis que a DayDate pode descrever. É possível esclarecer isso um pouco mais [N1]. 


c static final int EARLIEST DATE ORDINAL = 2; / 1/1/1900 
Static final int LATEST DATE ORDINAL - 2358465; // 12/31/9999 


Nao está claro para mim porque EARLIEST DATE ORDINAL é 2 em vez de 0. Há uma dica no 
comentário na linha 829 sugerindo que tem algo a ver com a forma de representação das datas no 
Microsoft Excel. A SpreadsheetDate (Listagem B.5, página 382), uma derivada de DayDate, 
possui uma explicação muito mais descritiva. O comentário na linha 71 descreve bem a questão. 
Meu problema com isso é que a questão parece estar relacionada à implementação de 
Spreadsheet Date е não tem nada a ver com Day Date. Cheguei à conclusão de que EARLIEST | 
DATE ORDINAL e LATEST DATE ORDINAL realmente não pertencem à DayDate e devem ser 
movidos para SpreadsheetDate [G6]. 

Na verdade, uma busca pelo código mostra que essas variáveis são usadas apenas dentro de 
SpreadsheetDate. Nada em DayDate ou em qualquer outra classe no framework JCommon as 
usa. Sendo assim, moverei-as abaixo para SpreadsheetDate. 

As variáveis seguintes, MINIMUM YEAR SUPPORTED e MAXIMUM YEAR SUPPORTED (linhas 
104 e 107), geram um dilema. Parece claro que, se DayDate é uma classe abstrata que nào dá 
nenhuma indicação de implementação, então ela não deveria nos informar sobre um ano mínimo 
ou máximo. Novamente, fico tentado a mover essas variáveis abaixo para SpreadsheetDate 
[G6]. Entretanto, uma busca rápida pelos usuários que as usam mostra que uma outra classe as 
usa: RelativeDayOfWeekRule (Listagem B.6, página 390). Vemos que,nas linhas 177 e 178 
na função getDate, as variáveis são usadas para verificar se o parâmetro para gecDate é um 
ano válido. O dilema é que um usuário de uma classe abstrata necessita de informações sobre 
sua implementação. 

O que precisamos é fornecer essas informações sem poluir a DayDate. Geralmente, pegariamos 
as informações da implementação a partir de uma instância de uma derivada. Entretanto, a função 
getDate não recebe uma instância de uma DayDate, mas retorna tal instância, o que significa que, 
em algum lugar, ela a deve estar criando. Da linha 187 a 205, dão a dica. A instância de DayDate 
é criada por uma dessas três funções: get PreviousDayOfWeek, getNearestDayOfWeek ou 
getFollowingDayOfWeek. 

Olhando novamente a listagem de DayDate, vemos que todas essas funcóes (linhas 638-724) 


de código aberto é melhor 
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retornam uma data criada por addDays (linha 571), que chama createInstance (linha 808), 
que cria uma SpreadsheecDate! [G7]. 

Costuma ser uma péssima ideia para classes base enxergar seus derivados. Para consertar isso, 
devemos usar o padrão ABSTRACT FACTORY? e criar uma DayDateFactory. Essa factory 
criará as instâncias de DayDate que precisamos e também poderá responder às questões sobre а 
implementação, como as datas mínima e máxima. 


t class DayDateFactory { 

factory = new SpreadsheetDateFactory(); 
tance (DayDateFacrory factory! 
y = factory: 


public static void set. 
DaybateFactory. fact 


protected abstract DayDate _makeDate(int ordinal); 

protected abstract DayDate  makeDate (int day, DayDate.Month month, int year); 
protected abstract DayDate _makeDate(int day, int month, int year); 
protected abstract DayDate _makeDate(java.util.Date datei; 

protected abstract int getMinimumYear(); 

protected abstract int _getMaximumYear(}; 


public static DayDate makeDate(int ordinali { 


return factory. makeDate (ordinal 


public static DayDate makeDate(int day, DayDate.Month month, int vear! ( 
return factory. makeDate (day, month, year); 


public static DayDate makeDate(int day, int month, int yeari ( 
return _makeDate (day, mo: ar): 
‚ 


public static DayDate makeDate(java.util.Date date) ( 
return factory. makeDate (date) 


} 


public static int getMinimumYear() ( 
return factory. getMinimumYear(!; 


} 
public static int getMaximumYear() { 


return factory. getMaximumYear (); 
} 


Essa classe factory substitui os métodos createInstance pelos makeDate, que melhora 
um pouco os nomes [N1]. O padrão se vira para SpreadsheetDateFactory, mas que pode ser 
modificado a qualquer hora para usar uma factory diferente. Os métodos estáticos que delegam 
responsabilidade aos métodos abstratos para usarem uma combinação dos padrões SINGLETON‘, 
DECORATOR‘ e ABSTRACT FACTORY, que tenho achado úteis. 

A SpreadsheetDateFactory se parece com isso: 


paia 
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public class SpreadsheetDateFactory extends DayDateFactory ( 
publie DayDate makeDate(int ordinal! ( 
return new SpreadsheetDate ordinal) 
1 


public DayDate | makeDate(int day, DayDate.Mcnth month, int year) { 
return new SpreadsheetDate(day, month, year); 
) 


public DayDate | makeDatelint day, int month. int year) ( 
return new SpreadsheetDate(day, month, year); 


public DayDate makeDate (Date date) ( 
final GregorianCalendar calendar = new GregorianCalendarí); 
calendar. setTime (дасе); 
return new SpreadsheetDate ( 
calendar .get (Calendar .DATE), 
DayDate.Month.make (calendar .get (Calendar .MONTH) + 1}, 
calendar.get (Calendar. YEAR 


} 


protected int _getMinimumYear() | 
return SpreadsheetDate.MINIMUM_YEAR_SUPPORTED; 
) 


protected int _getMaximumYear() { 
return SpreadsheetDate.MAXIMUM YEAR. 
} 


IPPORTED; 


Como pode ver, já movi as variáveis MINIMUM YEAR SUPPORTED e MAXIMUM YEAR 
SUPPORTED para onde elas pertencem [G6], em SpreadsheetDate. 

A próxima questão na DayDate são as constantes day que começam na linha 109. Isso deveria 
ser outro enum [13]. Já vimos esse padrão antes, portanto, nào о repetirei aqui. Você o verá nas 
últimas listagens. 

Em seguida, precisamos de uma série de tabelas começando com LAST. DAY OF MONTH na linha 
140. Meu primeiro problema com essas tabelas é que os comentários que as descrevem são 
redundantes [C3]. Os nomes estão bons. Sendo assim, irei excluir os comentários. 

Parece não haver uma boa razão para que essa tabela não seja privada [G8], pois existe uma 
função Last DayOfMonth estática que fornece os mesmos dados. 

A próxima tabela, AGGREGATE DAYS TO END OF MONTH, é um pouco mais enigmática, pois 
não é usada em lugar algum no framework JCommon [G9]. Portanto, excluí-a. 

O mesmo vale para LEAP YEAR AGGREGATE DAYS TO END OF MONTH. 

Apenas a SpreadsheetDate (linhas 434 e 473) usa a tabela seguinte, AGGREGATE DAYS TO END _ 
OF PRECEDING MONTH. Isso leva à questão se ela deve ser movida para SpreadsheetDate. 
O argumento para não fazê-lo é que a tabela não é específica a nenhuma implementação em 
particular [G6]. Por outro lado, não há implementação além da SpreadsheetDate, e, portanto, 
a tabela deve ser colocada próxima do local onde ela é usada. 

Para mim, o que decide é que para ser consistente [G11], precisamos tornar a tabela privada e 
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expó-la através de uma função, como a julianDateOfLastDayOfMonth. Parece que ninguém 
precisa de uma função como essa. Ademais, pode-se facilmente colocar a tabela de volta na 
classe DayDate se qualquer implementação nova desta precisar daquela. 

O mesmo vale para LEAP YEAR AGGREGATE DAYS TO END OF MONTH. 

Agora, veremos as três séries de constantes que podem ser convertidas em enum (linhas 162-205). 
A primeira das três seleciona uma semana dentro de um mês. Transformei-a em um enum 
chamado WeekInMonth. 


public enum WeekInMonth { 
FIRST(1), SECOND(2), THIRD(3), FOURTH(4), LAST(0): 
public final int index; 


WeekInMonth(int index) { 
this.index - index; 


} 


A segunda série de constantes (linhas 177-187) é um pouco mais confusa. Usam-se as constantes 
INCLUDE NONE, INCLUDE FIRST, INCLUDE SECOND e INCLUDE BOTH para descrever se as 
datas nas extremidades de um intervalo devam ser incluídas nele. Matematicamente, usam-se os 
termos “intervalo aberto”, “intervalo meio-aberto" e “intervalo fechado”. 

Acho que fica mais claro se usarmos a nomenclatura matemática [N3]. então transformei essa 
segunda série de constantes em um enum chamado Datelnterval com enumeradores CLOSED 
(fechado), CLOSED LEFT (esquerda fechado), CLOSED RIGHT (direta fechado) e OPEN (aberto). 
A terceira série de constantes (linhas 18-205) descreve se uma busca por um dia particular da 
semana deve resultar na última, na próxima ou na mais próxima instância. Decidir o nome disso 
é no mínimo difícil. No final, optei por WeekdayRange com enumeradores LAST (último), NEXT 
(próximo) e NEAREST (mais próximo). 

Talvez você não concorde com os nomes que escolhi. Para mim eles fazem sentido, pode não 
fazer para você. A questão é que agora cles estão num formato que facilita sua alteração [J3]. 
Eles não são mais passados como inteiros, mas como símbolos. Posso usar a função de “nome 
alterado” de minha IDE para mudar os nomes, ou os tipos, sem me preocupar se deixei passar 
algum -1 ou 2 em algum lugar do código ou se alguma declaração de um parâmetro do tipo int 
está mal descrito. 

Parece que ninguém usa о campo de descrição da linha 208. Portanto, eu a exclui juntamente 
com seu método de acesso e de alteração [G9]. 

Também deletei o danoso construtor padrão da linha 213 [G12]. O compilador o criará para nós. 
Podemos pular o método isValidWeekdayCode (linhas 216-238), pois o excluímos quando 
criamos a enumeração de Day. 

Isso nos leva ao método stringToWeekdayCode (linhas 242-270). Os Javadocs que nào 
contribui muito à assinatura do método são apenas restos [C3],[G12]. O único valor que 
esse Javadoc adiciona é a descrição do valor retornado -1. Entretanto, como mudamos para 
a enumeração de Day, o comentário está de fato errado [C2]. Agora o método lança uma 
IllegalArgumentExcepti on. Sendo assim, deletei о Javadoc. 

Também exclui a palavra reservada final das declarações de parâmetros e variáveis. Até onde 
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pude entender, ela não adicionava nenhum valor real, só adiciona mais coisas aos restos inúteis 
[G12]. Eliminar essas &na1 contraria alguns conhecimentos convencionais. Por exemplo, Robert 
Simons‘ nos aconselha a “...colocar final em todo o seu código”. Obviamente, eu discordo. 
Acho que há alguns poucos usos para o final, como a constante final, mas fora isso, as palavras 
reservadas acrescentam pouca coisa e criam muito lixo. Talvez eu me sinta dessa forma porque 
os tipos de erros que o final possa capturar, os testes de unidade que escrevi já о fazem. 

Não me importo com as estruturas if duplicadas [G5] dentro do loop for (linhas 259 e 263). 
portanto, eu os uni em um único i£ usando o operador | | Também usei a enumeração de Day 
para direcionar o loop for e fiz outros retoques. 

Ocorreu-me que este método não pertence à DayDate. Ele é a função de análise sintática de 
Day. Então o movi para dentro da enumeração de Dav, a qual ficou muito grande. Como Day não 
depende de DayDate, retirei a enumeração de Day da classe DayDate е coloquei em seu próprio 
arquivo fonte [613]. 

Também movi a próxima função, weekdayCodeToString (linhas 272-286) para dentro da 
enumeração de Day e a chamei de tostring. 


public enum Day ( 

MONDAY (Calendar . MONDAY), 

TUESDAY (Calendar . TUESDAY), 
WEDNESDAY (Calendar WEDNESDAY) , 5 
THURSDAY (Calendar. THURSDAY), 
FRIDAY (Calendar. FRIDAY), 
SATURDAY (Calendar . SATURDAY) , 
SUNDAY (Calendar . SUNDAY) ; 


public final int index; 
private static DateFormatSymbols dateSymbols = new DateFormatSymbols i); 


Day (int day) ( 
index = day; 
) 


public static Day make(int index) throws IllegalArgumentException { 
for (Day а : Day.values()) 
if (d.index == index) 
return d; 
throw new Illegalargument Except ion ( 
String. format ("Illegal day index: $&d.', index)); 


) 


public static Day parse(String s) throws IllegalArgumentException | 
String[] shortWeekdayNames - 
dateSymbols.getShortWeekdays () ; 
String[] weekDayNames = 
dateSymbols.getiWeekdays () ; 


s = s.trim(); 
ior (Day day : Day.values()) ( 
if (s.equalsIgnoreCase(shortWeekdayNames [day . index]; || 
s.equalsIgnoreCase (weekDayNames[day.index]]) ( 
return dav; 
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} 
throw new IllegalArgumentExceptioni 
string. format ("$s is not a valid weekday string", Sì); 
i 
public String toString() ( 
return dateSymbols.getWeekdays () [index]; 
} 


Ha duas funções getMonths (linhas 288-316). A primeira chama a segunda. Esta só é chamada 
por aquela. Sendo assim, juntei as duas numa única só e as simplifiquei consideravelmente 
[G9].[G12].[F4]. Por fim, troquei o nome para ficar um pouco mais descritivo [N1]. 


public static String[] getMonthNamesi) ( 
return dateFormatSymbols .getMonths() ; 


A função isValidMonthCode (linhas 326-346) se tornou irrelevante devido ao enum Month. 
Portanto, deletei-a [G9]. A função monthCodeToQuarter (linhas 356—375) parece a FEATURE 
ENVY’ [G14] e, provavelmente, pertence a enum Moth como um método chamado quarter. 
Portanto, exclui-a. 


public int quarter() { 
return 1 + {index-1)/3; 
i 


Isso deixou o enum Month grande o suficiente para ter sua própria classe. Sendo assim, retirei-o 
de DayDate para ficar mais consistente com o enum Day [G11],[G13]. 

Os dois métodos seguintes chamam-se monthCodeTostring (linhas 377-426). Novamente, 
vemos um padrão de um método chamando sua réplica com uma flag. Costuma ser uma péssima 
idéia passar uma flag como parâmetro de uma função, especialmente qual a flag simplesmente 
seleciona o formato da saída [G15]. Renomeei. simplifiquei e reestruturei essas funções e as 
movi para o enum Month [N1],[N3],[C3],[G14]. 


public String toStringi) { 
return dateFormatSynbols.getMonthsi) [index - 1]; 


) 


public String toShortString() { 
return dateFormatSymbols.getShortMonths() [index - 1]; 
1 


O próximo método é o stringToMonthCode (linhas 428-472). Renomeei-o, movi-o para enum 
Month e o simplifiquei [N1],[N3],[C3],[G14],[G12]. 
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static Month parse(String s) ( 
s.trim() 


for iMonth m : Month.values(1) 
if (m.matches(s)) 
return m; 
try ( 


return make (Integer .parseInt (si); 
) 
catch iNumberFormatException e) () 
throw new IllegalArgumentException(*Invalid month * + s); 


private boolean matches(String s) { 
return s.equalsIgnoreCase(toString()) || 
8.equalsIgnoreCase (toShortString()); 


É possível tornar o método isLeapYear (linhas 495-517) um pouco mais expressivo [G16]. 


public static boolean isLeapYear(int year) ( 
boolean fourth = year % 4 == 0; 
boolean hundredth = year $ 100 
boolean fourHundredth year % 400 0; 
return fourth && (!hundredth || fourHundredth); 
) 


A próxima função, 1eapYearCount (linhas 519—536), realmente não pertence a DayDate. 
Ninguém a chama, exceto pelos dois métodos em spreadsheet Date. Portanto, a movi para 
baixo [G6]. 

A função lastDayOfMonth (linhas 538—560) usa o array LAST. DAY. OF. MONTH, que pertence 
a enum Month [G17]. Portanto, movi-a para lá e também a simplifiquei e a tornei um pouco mais 
expressiva [G16]. 


public static int lastDayOfMonth (Month month, int year) { 
if (month == Month.FEBRUARY && isLeapYear (year) ) 
return month. lastDay() + 1; 
else 
return month. lastDay(); 


Agora as coisas estão ficando mais interessantes. A função seguinte é a addDays (linhas 562— 
576). Primeiramente, como ela opera nas variáveis de DayDate, ela não pode ser estática [G18]. 
Sendo assim, a transformei na instância de um método. Segundo, ela chama a função toSerial, 
que deve ser renomeada para toOrdinal [N1]. Por fim, é possível simplificar o método. 


public DayDate addDays(int days) ( 
return DayDatePactory.makeDate(toOrdinal() + days); 
) 
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O mesmo vale para addMonths (linhas 578—602), que deverá ser a instância de um método. 

O algoritmo está um pouco mais complicado, então usei VARIÁVEIS TEMPORÁRIAS 
EXPLICATIVAS (EXPLAINING TEMPORARY VARIABLES?) para ficar mais transparente. 
Também renomeei o método gecvvv para getvear [NI]. 


public DayDate addMonths(int months) ( 
int thisMonthAsOrdinal = 12 * getYeari) + getMonth().index - 
int resultMonthAsOrdinal = thisMonthAsGrdinal + months: 
int resultYear = resultMonthAsOrdinal / 
Month resultMonth = Month. make (resuitMonth? isOrdinal $ 1 


int lastDayOfResultMonth = lastDayOfMonth(resultMonth, resultYear); 
int resultDay = Math.min(getDayOfMonth(), lastDayOfResultMonth) ; 
return DayDateFactory.makeDate(resultDay, resultMonth, resultYear); 


A função addvears (linhas 604—626) não possui nada de extraordinário em relação às outras. 


public DayDate p. ars(int years) | 

int resultYear - getYear() * year: 

int lastDayOrMonthInResultYear ayOfMonth(getMonth(!, resultYear); 
int resultDay = Math.min(getDayOfMonth(), lastDayOfMonthInResultYear); 
return DayDateFactory.makeDate(resultDay, getMonth(), resultYear); 


H 


Estou com uma pulga atrás da orelha sobre alterar esses métodos de estáticos para instâncias. A 
expressão date. addDays(5) deixa claro que o objeto date não é alterado e que é retornada uma 
nova instância de DayDate? 

Ou indica erroneamente que estamos adicionando cinco dias ao objeto date? Você pode achar 
que isso não seja um grande problema, mas um pedaço de código parecido com o abaixo pode 
enganar bastante [620]. 


DayDate date = DateFactory.makeDate(5, Month.DECEMBER, 1952); 
date.addDays(7); // pula a data em uma semana. 


Alguém lendo esse código muito provavelmente entenderia apenas que addDays está alterando 
0 objeto date. Portanto, precisamos de um nome que acabe com essa ambiguidade [N4]. Sendo 
assim, troquei os nomes de plusDays e plusMonths. Parece-me que a expressão abaixo indica 
bem o objetivo do método: 


DayDate date = oldDate.plusDays(5); 


Por outro lado, a instrução abaixo não é o suficiente para que o leitor deduza que o objeto date 
fora modificado: 


date.plusDays(5); 


Os algoritmos continuam a ficar mais interessantes. get PreviousDayOfWeek (linhas 628- 
660) funciona, mas está um pouco complicado. Após pensar um pouco sobre o que realmente 
está acontecendo [G21]. fui capaz de simplificá-lo e usar as VARIÁVEIS TEMPORÁRIAS 
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EXPLICATIVAS [G19] para esclarecê-lo. Também a passei de um método estático para a 
instância de um método [G18], e me livrei das instâncias duplicadas [G5] (linhas 997-1008). 


public DayDate getPreviousDayOfWeek(Day targetDayOfWeek) ( 
int offsetToTarget = targetDayOfWeek.index - getDayOfWeekí!.index; 
if (offsetToTarget 0) 
offsetToTarget -= 
return plusDays (offsetToTarget) ; 


Exatamente o mesmo ocorreu com getFollowingDayOfWeek (linhas 662-693). 


public DayDate getFollowingDayOfWeek(Day targetDayOfWeek) ( 
int offsetToTarget = targetDayOfWeek.index - getDayOfWeek().index; 
if (offsetToTarget «- 0) 


offsetToTarget += 7; 
return plusDays ioffsetToTarget); 
} В 


Consertamos a função seguinte, gecNearesrDayOfWeek (linhas 695—726), na página 270. Mas 
as alterações que fiz naquela hora não eram consistentes com o padrão atual nas duas últimas 
funções [G11]. Sendo assim, tornei-a consistente e usei algumas VARIÁVEIS TEMPORÁRIAS 
EXPLICATIVAS [G19] para esclarecer o algoritmo. 


public DayDate gerNearestDay0fWeek (Final Day targetDay) ( 
int offsetToThisWeeksTarget = targetDay - getDavOfWeek(). index; 
int offsetToFutureTarget = (offsetToThisWeeksTarget + 7) $ 7; 
int offsetToPreviousTarget = offsetToFutureTarget - 7; 


if (offsetToFutureTarget > 3) 

return plusDays (offsetToPreviousTarget); 
else 

return plusDays (offsetToFutureTarget) ; 


O método getEndOfCurrentMonth (linhas 728—740) está um pouco estranho por ser a instância 
de um método que inveja [G14] sua própria classe ao receber um parâmetro DayDate. Tornei-o 
a instância de um método real e esclareci alguns nomes. 


public DayDate getEndOfMonth() ( 
Month month = getMonth(); 

int year = getYear (); 
lastDay0iMonth (month, year); 

return DayDateFactory .makeDate (last. month, year) 
} 
De fato, refatorar weekInMonthToString (lines 742-761) acabou sendo bem interessante. 
Usando as ferramentas de refatoração de minha IDE, primeiro movi o método para o enum 
WeekinMonth que criei na página 275. Então, renomeei o método para toString. Em seguida, 
alterei-o de um método estático para a instância de um método. Todos os testes ainda passavam 


com êxito (Já sabe o que vou fazer?). 
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Depois excluí o método inteiro! Cinco testes de confirmação falharam (linhas 41 1-415, Listagem 
B.4, página 374). Alterci essas linhas para usarem os nomes dos enumeradores (FIRST, SECOND, 
. . .). Todos os testes passaram. Consegue ver por quê? Consegue ver também por que foi preciso 
cada um desses passos? A ferramenta de refatoração garantiu que todos os chamadores de 
weekInMonthToString agora invocassem toString no enum weekInMonth, pois todos os 
enumeradores implementam toString para simplesmente retornarem seus nomes... 
Infelizmente, fui esperto demais. Por mais elegante que estivesse aquela linda sequência de 
refatorações, finalmente percebi que os únicos usuários dessa função eram os testes que eu 
acabara de modificar, portanto os exclui. 

Enganou-me de novo, tenha vergonha na cara! Enganou-me duas vezes, eu é quem preciso 
ter vergonha na cara! Então, depois de determinar que ninguém além dos testes chamava 
relativeToString (linhas 765—781), simplesmente deletei a função e seus testes. 
Finalmente chegamos aos métodos abstratos desta classe abstrata. E o primeiro não poderia ser 
mais apropriado: toSer i a1 (linhas 838-844). Lá na página 279, troquei o nome para toOrdinal. 
Analisando isso com o contexto atual, decidi que o nome deve ser getOrdinalDay. 

O próximo método abstrato é o toDate (linhas 838-844). Ele converte uma DayDate para 
uma java.util.Date. Por que o método é abstrato? Se olharmos sua implementação na 
SpreadsheetDate (linhas 198-207, Listagem B-5, página 382), vemos que ele nào depende 
de nada na implementação daquela classe [G6]. Portanto, o movi para cima. 

Os métodos getY YYY, getMonth e getDayOfMonth estão bem como abstratos. Entretanto, o 
getDayOfWeek é outro que deve ser retirado de SpreadsheetDate, pois ele não depende de 
nada que esteja em DayDate [G6]. Ou depende? 

Se olhar com atenção (linha 247, Listagem B-5, página 382), verá que o algoritmo implicitamente 
depende da origem do dia ordinal (ou seja, do dia da semana do dia 0). Portanto, mesmo que essa 
função não tenha dependências físicas que possam ser movidas para DayDate, ela possui uma 
dependência lógica. 

Dependências lógicas como essa me incomodam [G22]. Se algo lógico depende da implementação, 
então algo físico também depende. Ademais, parece-me que o próprio algoritmo poderia ser 
genérico com uma parte muito menor de si dependendo da implementação [G6]. 

Sendo assim, criei um método abstrato getDayOfWeekForOrdinalZero em DayDate 
e o implementei em SpreadsheetDate para retornar Day.SATURDAY. Então, subi o 
método getDayOfWeek para a DayDate e o alterei para chamar getOrdinalDay € 
getDayOfWeekForOrdinalZero. 


public Day getDayOfWeek!) { 
Day startingDay = getDayOfWeekForOrdinalZero() + 
int startingOffset artingDay.index - Day. SUNDAY. index; 
return Day .make( (getOrdinalDay() + startingOffseti $ 7 + 1); 


Como uma observação, olhe atentamente o comentário da linha 895 até a 899. Essa repetição era 
realmente necessária? Como de costume, exclui esse comentário juntamente com todos os outros. 
O próximo método é o compare (linhas 902-913). Novamente, ele não está adequadamente 
abstrato [G6], de modo que subi sua implementação para DayDate. Ademais, o nome não diz 
muito [N1]. Esse método realmente retorna a diferença em dias desde o passado por parâmetro. 
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Sendo assim, mudei seu nome para daysSince. Também notei que não havia testes para este 
método, então os escrevi. 

As seis funções seguintes (linhas 915-980) são todas métodos abstratos que devem ser 
implementados em DayDate, onde os coloquei após retirá-los de SpreadsheetDate. 

A última função, isInRange (linhas 982-995), também precisa ser movida para cima e 
refatorada. 

A estrutura switch está um pouco feia [G23] e pode-se substitui-la movendo os case para o 
enum DateInterval. 


public enum DateInterval ( 


OFEN ( 
public boolean isIn(int d, int left, int right) ( 
return d » left && d « right; 
) 
), 
CLOSED LEFT ( 
public boolean isIn{int d, int left, int right) ( 
return d >= leit && d « right; 
1, 
CLOSED RIGHT { 
public boolean isin(int d 
return d > left && d < 
) 


int left, int right) ( 
right; 


h 
CLOSED ( 
public boolean isIn(int d, int left, int right) 
return d >= left БЕ d <= right: 
E 


public abstract boolean isIn(int d, int left, int right); 


public boolean isInRange(DayDate dl, DayDate d2, DateInterval interval) ( 
int left = Math.min(dl.getOrdinalDay (), d2.getOrdinalDay()); 
int right = Math.max(d1.getOrdinalDay(), d2.getordinslDay()); 
return interval.isIn(getGrdinalDay(), left, right); 


Isso nos leva ao final de DayDate. Entào, agora vamos dar mais uma passada por toda a classe 
para ver como ela flui. 

Primeiramente, o comentário de abertura está desatualizado, entào o reduzi e o melhorei [C2]. 
Depois, movi todos os enum restantes para seus próprios arquivos [G12]. 

Emseguida, moviavariávelestáticadateFormatSymbols etrésmétodosestáticos(getMonthNames, 
isLeapYear, lastDayOfMonth) para uma nova classe chamada Dateutil [G6]. 

Subi os métodos abstratos para o topo, onde eles pertencem [G24]. 

Alterei de Month. make para Month. fromInt [№] e fiz o mesmo com todos os outros enums. 
Também criei um método acessor toInt para todos os enum c tornei privado o campo index. 
Havia umas duplicações interessantes [G5] em plusvears e em plusMonths que fui capaz de 


Primeiro, faça-a funcionar 279 


eliminar extraindo um novo método chamado correctLastDayOfMonth, о que deixou todos 
os três métodos muito mais claros. 

Livrei-me do número mágico 1 [G25], substituindo-o por Month. JANUARY. toTnt () ou Day. 
SUNDAY. toInt (), conforme apropriado. Gastei um tempo limpando um pouco os algoritmos de 
SpreadsheetDate. O resultado final vai da Listagem B.7 (p. 394) até a Listagem B.16 (p. 405). 

É interessante como a cobertura dos testes no código de DayDate caiu para 84.9%! Isso não 
se deve à menor quantidade de funcionalidade testada, mas à classe que foi tão reduzida que as 
poucas linhas que não eram testadas eram o maior problema. Agora a DayDate possui 45 de 53 
instruções executáveis cobertas pelos testes. As linhas que não são cobertas são tão triviais que 
não vale a pena testá-las. 


Conclusão 

Então, mais uma vez seguimos a Regra de Escoteiro. Deixamos o código um pouco mais limpo 
do que antes. Levou um tempo, mas vale a pena. Aumentamos a cobertura dos testes, consertamos 
alguns bugs e esclarecemos e reduzimos o código. Espero que a próxima pessoa que leia este 
código ache mais fácil lidar com ele do que nós achamos. Aquela pessoa provavelmente também 
será capaz de limpá-lo ainda mais do que nós. 
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Odores e Heurísticas 


Em seu magnífico livro Refatoração!, Martin Fowler identificou muitos “odores diferentes 
de código”. A lista seguinte possui muitos desses odores de Martin e muitos outros meus. Há 
também outras pérolas e heurísticas que uso para praticar meu ofício. 
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Compilei essa lista ao analisar e refatorar diferentes programas. Conforme os alterava, eu me 
perguntava por que fiz aquela modificação e, então, escrevia o motivo aqui. O resultado é uma 
extensa lista de coisas que cheiram ruim para mim quando leio um código. 

Esta lista é para ser lida de cima para baixo e também se deve usá-la como referência. 

Há uma referência cruzada para cada heurística que lhe mostra onde está o que é referenciado no 
resto do texto no Apéndice C na página 409. 


Comentários 
C1: Informações inapropriadas 


Não é apropriado para um comentário deter informações que ficariam melhores em um outro 
tipo diferente de sistema, como o seu sistema de controle de seu código-fonte, seu sistema 
de rastreamento de problemas ou qualquer outro sistema que mantenha registros. Alterar 
históricos, por exemplo, apenas amontoa os arquivos fonte com volumes de textos passados е 
desinteressantes. De modo geral, metadados, como autores, data da última atualização, número 
SRP e assim por diante, não deve ficar nos comentários. Estes devem conter apenas dados 
técnicas sobre o código e o projeto. 


C2: Comentário obsoleto 


Um comentário que ficou velho. irrelevante e incorreto é obsoleto. Comentários ficam velhos 
muito rápido, logo é melhor não escrever um que se tornará obsoleto. Caso você encontre um, é 
melhor atualizá-lo ou se livrar dele o quanto antes. Comentários obsoletos tendem a se desviar 
do código que descreviam. Eles se tornam ilhas flutuantes de irrelevancia no código e passam 
informações erradas. 


C3: Comentários redundantes 


Um comentário é redundante se ele descreve algo que já descreve a si mesmo. Por exemplo: 


i++; // incrementa i 


Outro exemplo é um Javadoc que nada diz além da assinatura da função: 


pra 

* @param sellRequest 

* (return 

* éthrows ManagedComponentException 

4 

public SellResponse beginSellitem(SellRequest sellRequest) 
throws ManagedComponentException 


Os comentários devem informar o que o código não consegue por si só. 


Ambiente 283 


C4: Comentário mal escrito 


Um comentário que valha ser escrito deve ser bem escrito. Se for criar um, não tenha pressa e 
certifique-se de que seja o melhor comentário que você já escreveu. Selecione bem suas palavras. 
Use corretamente a gramática e a pontuação. Não erre. Não diga o óbvio. 

Seja breve. 


C5: Código como comentário 


Fico louco ao ver partes de código como comentários. Quem sabe a época em que foi escrito? 
Quem sabe se é ou não significativo? Mesmo assim, ninguém o exclui porque todos assumem 
que outra pessoa precisa dele ou tem planos para ele. 

O código permanece lá e apodrece, ficando cada vez menos relevante a cada dia que passa. 
Ele chama funções que não existem mais: usa variáveis cujos nomes foram alterados; segue 
convenções que há muito se tornaram obsoletas; polui os módulos que o contêm e distrai as 
pessoas que tentam lê-lo. Colocar códigos em comentários é uma abominação. 

Quando você vir um código como comentário, exclua-o! Não se preocupe, o sistema de controle 
de código fonte ainda se lembrará dele. Se alguém precisar dele, poderá verificar a versão anterior. 
Não deixe que códigos como comentários existam. 


Ambiente 
El: Construir requer mais de uma etapa 


Construir um projeto deve ser uma operação simples e única. Você não deve: verificar muitos 
pedacinhos do controle de código-fonte; precisar de uma sequência de comandos arcaicos ou 
scripts dependentes de contexto de modo a construir elementos individuais; ter de buscar perto 
e longe vários JARs extras, arquivos XML e outros componentes que o sistema precise. E você 
deve ser capaz de verificar o sistema com um único comando e, então, dar outro comando simples 
para construí-lo. 


svn get mySystem 
cd mySystem 
ant all 


E2: Testes requerem mais de uma etapa 


Vocé deve ser capaz de rodar todos os testes de unidade com apenas um comando. No melhor 
dos casos, você pode executar todos ao clicar em um botão em sua IDE. No pior, você deve ser 
capaz de dar um único comando simples numa shell. Poder rodar todos os testes é tão essencial 
€ importante que deve ser rápido, fácil e óbvio de se fazer. 
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Funções 
F1: Parâmetros em excesso 


As funções devem ter um número pequeno de parâmetros. Ter nenhum é melhor. Depois vem 
um, dois e três, Mais do que isso é questionável e deve-se evitar com preconceito. 
(Consulte Parâmetros de funções na página 40.) 


F2: Parâmetros de saída 


Os parâmetros de saída são inesperados. Os leitores esperam que parâmetros sejam de entrada, e 
não de saída. Se sua função deve alterar o estado de algo, faça-a mudar o do objeto no qual ela é 
chamada. (Consulte Parâmetros de saída na página 45.) 


F3: Parâmetros lógicos 


Parâmetros booleanos explicitamente declaram que a função faz mais de uma coisa. Eles são 
confusos e se devem eliminá-los (Consulte Parâmetros lógicos na página 41). 


F4: Função morta 


Devem-se descartar os métodos que nunca são chamados. Manter pedaços de código mortos é 
devastador. Não tenha receio de excluir a função. Lembre-se de que seu o sistema de controle de 
código fonte ainda se lembrará dela. 


Geral 
G1: Múltiplas linguagens em um arquivo fonte 


Os ambientes modernos de programação atuais possibilitam colocar muitas linguagens distintas 
em um único arquivo fonte. Por exemplo, um arquivo-fonte Java pode conter blocos em XML, 
HTML, YAML, JavaDoc, português, JavaScript, etc. Outro exemplo seria adicionar ao HTML 
um arquivo JSP que contenha Java, uma sintaxe de biblioteca de tags, comentários em português, 
Javadocs, etc. Na melhor das hipóteses, isso é confuso, e na pior, negligentemente desleixado. 
O ideal para um arquivo-fonte é ter uma, apenas uma, linguagem. Mas na vida real, provavelmente 
teremos de usar mais de uma. Devido a isso, devemos minimizar tanto a quantidade como o uso 
de linguagens extras em nossos arquivos-fonte. 


G2: Comportamento óbvio não é implementado 


Seguindo o “Princípio da Menor Supresa”?, qualquer função ou classe deve implementar os 
comportamentos que outro programador possivelmente esperaria. Por exemplo, considere uma 
função que traduza o nome de um dia em um enum que represente o dia. 


Day day = DayDate.StringToDay(String dayName); 


VEN PRP ÇA, E A 
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Esperamos que a string “Segunda” seja traduzido para Dia. SEGUNDA. Também esperamos 
que as abreviações comuns sejam traduzidas, e que a função não faça a distinção entre letras 
maiúsculas e minúsculas. 

Quando um comportamento não é implementado, os leitores e usuários do código não podem 
mais depender de suas intuições sobre o que indica o nome das funções. Aquelas pessoas perdem 
a confiança no autor original e devem voltar e ler todos os detalhes do código. 


G3: Comportamento incorreto nos limites 


Parece óbvio dizer que o código deva se comportar corretamente. O problema é que raramente 
percebemos como é complicado um comportamento correto. Desenvolvedores geralmente criam 
funções as quais eles acham que funcionarão, e, então, confiam em suas intuições em vez de se 
esforçar para provar que o código funciona em todos os lugares e limites. 

Não existe substituição para uma dedicação minuciosa. Cada condição de limite, cada canto do 
código. cada trato e exceção representa algo que pode estragar um algoritmo elegante c intuitivo. 
Não dependa de sua intuição. Cuide de cada condição de limite e crie testes para cada. 


G4: Seguranças anuladas 


Chernobyl derreteu porque o gerente da planta anulou cada um dos mecanismos de segurança, 
um a um. Os dispositivos de segurança estavam tornando inconveniente a execução de um 
experimento. O resultado era que o experimento não rodava, e o mundo viu a maior catástrofe 
civil nuclear. 

É arriscado anular as seguranças. Talvez seja necessário forçar o controle manual em 
serialVersionUID, mas há sempre um risco. Desabilitar certos avisos (ou todos!) do compilador 
talvez ajude a fazer a compilação funcionar com êxito, mas com o risco de infindáveis sessões 
de depuração. Desabilitar os testes de falhas e dizer a si mesmo que os aplicará depois é tão ruim 
quanto fingir que seus cartões de crédito sejam dinheiro gratuito. 


G5: Duplicação 


Essa é uma das regras mais importantes neste livro, e você deve levá-la muito a sério. Praticamente, 
todo autor que escreve sobre projetos de software a mencionam. Dave Thomas e Andy Hunt a 
chamaram de princípio de DRY? (Princípio do Não Se Repita), o qual Kent Beck tornou o centro 
dos princípios da eXtreme Programming (XP) e o chamou de “Uma vez, e apenas uma”. 

Ron Jeffries colocou essa como a segunda regra, sendo a primeira aquela em que se deve fazer 
todos os testes passarem com êxito. 

Sempre que você vir duplicação em código, isso significa que você perdeu uma chance para 
. Aquela duplicação provavelmente poderia se tornar uma sub-rotina ou talvez outra classe 
completa. Ao transformar a duplicação em tal , você aumenta o vocabulário da linguagem de seu 
projeto. Outros programadores podem usar os recursos de que você criar, E a programação se 
torna mais rápida e menos propensa a erros devido a você ter elevado o nível de . 

A forma mais óbvia de duplicação é quando você possui blocos de código idênticos, como se 
alguns programadores tivessem saído copiando e colando o mesmo código várias vezes. Aqui se 
deve substituir por métodos simples. Uma forma mais simples seriam as estruturas aninhadas de 
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switch/case е if/else que aparecem repetidas vezes em diversos módulos, sempre testando 
as mesmas condições. Nesse caso, deve-se substituir pelo polimorfismo. 

Formas ainda mais sutis seriam os módulos que possuem algoritmos parecidos, mas que não 
possuem as mesmas linhas de código. Isso ainda é duplicação e deveria-se resolvê-la através do 
padrão TEMPLATE METHOD‘ ou STRATEGY. 

Na verdade, a maioria dos padrões de projeto que têm surgido nos últimos 15 anos são 
simplesmente maneiras bem conhecidas para eliminar a duplicação. Assim como as regras de 
normalização (Normal Forms) de Codd são uma estratégia para eliminar a duplicação em bancos 
de dados. A OO em si — e também a programação estruturada — é uma tática para organizar 
módulos e eliminar a duplicação. 

Acho que a mensagem foi passada: encontre e elimine duplicações sempre que puder. 


G6: Códigos no nível errado de abstração 


É importante criar abstrações que separem conceitos gerais de níveis mais altos dos conceitos 
detalhados de níveis mais baixos. Аз vezes, fazemos isso criando classes abstratas que 
contenham os conceitos de níveis mais altos e gerando derivadas que possuam os conceitos 
de níveis mais baixos. Com isso, garantimos uma divisão completa. Queremos que todos os 
conceitos de níveis mais altos fiquem na classe base e que todos os de níveis mais baixos 
fiquem em suas derivadas. 

Por exemplo, constantes, variáveis ou funções que possuam apenas a implementação detalhada 
não devem ficar na classe base. Essa nào deve enxergar o resto. 

Essa regra também se aplica aos arquivos-fonte, componentes e módulos. Um bom projeto 
de software exige que separemos os conceitos em níveis diferentes e que os coloquemos em 
contêineres distintos. De vez em quando, esses contêineres são classes base ou derivadas, e, às 
vezes, arquivos-fonte, módulos ou componentes. Seja qual for o caso, a separação deve ser total. 
Não queremos que os conceitos de baixo e alto níveis se misturem. 

Considere o código seguinte: 


public interface Stack ( 
Object pop() throws EmptyException; 
void push(Object o) throws FullException; 
double percentFull(); 
class EmptyException extends Exception () 
class FullException extends Exception () 
} 


A função percentFu11 está no nível errado de . Embora haja muitas implementações de stack 
onde o conceito de plenitude seja razoável, existem outras implementações que simplesmente 
não poderiam enxergar quão completas elas são. Sendo assim, seria melhor colocar a função em 
uma interface derivada, como a BoundedStack. 

Talvez você esteja pensando que a implementação poderia simplesmente retornar zero se a pilha 
(stack) fosse ilimitada. O problema com isso é que nenhuma pilha é realmente infinita. Você não 
consegue evitar uma OutOfMemoryException ao testar 


stack.percentFull() < 50.0. 


4.[GOF]- 
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Implementar a função para retornar zero seria mentir. 

A questão é que você não pode mentir ou falsificar para consertar uma mal posicionada. Isolar 
as abstrações é uma das coisas mais difíceis para os desenvolvedores de software, e não há uma 
solução rápida quando você erra. 


G7: As classes base dependem de suas derivadas 


“A razão mais comum para separar os conceitos em classes base e derivadas é para que os conceitos 
de níveis mais altos das classes base possam ficar independentes dos conceitos de níveis mais 
baixos das classes derivadas. Portanto, quando virmos classes base mencionando o* nomes de 
suas derivadas, suspeitaremos de um problema. De modo geral, as classes base não deveriam 
enxergar nada em suas derivadas. 

Essa regra possui exceções, é claro. De vez em quando, o número de derivadas é fixado, e a 
classe base tem códigos que consultam suas derivadas. Vemos isso em muitas implementacóes 
de máquinas com configuração finita. Porém, neste caso, as classes base e derivadas estão 
fortemente acopladas e são sempre implementadas juntas no mesmo arquivo jar. De modo geral, 
queremos poder implementar as classes base e derivadas em arquivos jar diferentes. 

Conseguir isso e garantir que os arquivos base jar não enxerguem o conteúdo dos arquivos derivados 
jar, nos permite implementar nossos sistemas em componentes independentes e distintos. Ao serem 
modificados, podem-se implementar novamente esses componentes sem ter de fazer o mesmo com 
os componentes base. Isso significa que o impacto de uma alteração é consideravelmente reduzido, 
e fazer a manutenção dos sistemas no local se torna muito mais simples. 


G8: Informações excessivas 


Módulos bem definidos possuem interfaces pequenas que lhe permite fazer muito com pouco. 
Já os mal definidos possuem interfaces grandes e longas que lhe obriga a usar muitas formas 
diferentes para efetuar coisas simples. Uma interface bem definida não depende de muitas 
funções, portanto, o acoplamento é fraco. E uma mal definida depende de diversas funções que 
devem ser chamadas, gerando um forte acoplamento. 

Bons desenvolvedores de software aprendem a limitar o que expõem nas interfaces de suas 
classes e módulos. Quanto menos métodos tiver uma classe, melhor. Quanto menos variáveis 
uma função usar, melhor. Quanto menos variáveis tiver uma classe, melhor. 

Esconda seus dados. Esconda suas funções utilitárias. Esconda suas constantes e suas variáveis 
temporái 
Não crie classes com muitos métodos ou instâncias de variáveis. Não crie muitas variáveis e 
funções protegidas para suas subclasses. Concentre-se em manter as interfaces curtas e muito 
pequenas. Limite as informações para ajudar a manter um acoplamento fraco. 


G9: Código morto 


Um código morto é aquele nào executado. Pode-se encontrá-lo: no corpo de uma estrutura if 
que verifica uma condição que não pode acontecer; no bloco catch de um try que nunca 
ocorre: em pequenos métodos utilitários que nunca são chamados ou em condições da estrutura 
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switch/case que nunca ocorrem. 

O problema com códigos mortos é que após um tempo ele começa a “cheirar”. Quanto mais antigo 
ele for, mais forte e desagradável o odor se torna. Isso porque um código morto não é atualizado 
completamente quando um projeto muda. Ele ainda compila, mas não segue as novas convenções 
ou regras. Ele foi escrito numa época quando o sistema era diferente. Quando encontrar um 
código morto, faça a coisa certa. Dê a ele um funeral decente. Exclua-o do sistema. 


G10: Separação vertical 


Devem-se declarar as variáveis e funções próximas de onde são usadas. Devem-se declarar as 
variáveis locais i,nediatamente acima de seu primeiro uso, e o escopo deve ser vertical. Não queremos 
que variáveis locais sejam declaradas centenas de linhas afastadas de onde são utilizadas. 
Devem-se declarar as funções provadas imediatamente abaixo de seu primeiro uso. Elas 
pertencem ao escopo de toda a classe. Mesmo assim. ainda desejamos limitar a distância vertical 
entre as chamadas e as declarações. Encontrar uma função privada deve ser uma questão de 
buscar para baixo a partir de seu primeiro uso. 


G11: Inconsistência 


Se você fizer algo de uma determinada maneira, faça da mesma forma todas as outras coisas 
similares. Isso retoma o princípio da surpresa mínima. Atenção ao escolher suas convenções. 
Uma vez escolhidas, atente para continuar seguindo-as. 

Se dentro de uma determina função você usar uma variável de nome response para 
armazenar uma HttpServletResponse. então use o mesmo nome da variável de nome 
consistente nas outras funções que usem os objetos HttpServletResponse. Se chamar 
um método de processVerificationRequest, então use um nome semelhante, como 
processDeletionRequest, para métodos que processem outros tipos de pedidos (request). 
Uma simples consistência como essa, quando aplicada corretamente, pode facilitar muito mais a 
leitura e a modificação do código. 


G12: Entulho 


De que serve um construtor sem implementação alguma? Só serve para amontoar o código com 
pedaços inúteis. Variáveis que não são usadas, funções que jamais são chamadas, comentários 
que não acrescentam informações e assim por diante, são tudo entulhos e devem ser removidos. 
Mantenha seus arquivos-fonte limpos, bem organizados e livres de entulhos. 


G13: Acoplamento artificial 


Coisas que não dependem uma da outra não devem ser acopladas artificialmente. Por exemplo. 
enums genéricos não devem ficar dentro de classes mais específicas, pois isso obriga todo o 
aplicativo a enxergar mais essas classes. O mesmo vale para funções estáticas de propósito 
geral declaradas em classes específicas. 

De modo geral, um acoplamento artificial é um acoplamento entre dois módulos que não possuem 
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um propósito direto. Isso ocorre quando se colocar uma variável, uma constante ou uma função 
em um local temporariamente conveniente. porém inapropriado. Isso é descuido e preguiça. 
Tome seu tempo para descobrir onde devem ser declaradas as funções, as constantes e as 
variáveis. Não as jogue no local mais conveniente e fácil e as deixe lá. 


G14: Feature Envy 


Esse é um dos smels* (odores) de código de Martin Fowler. Os métodos de uma classe devem 
ficar interessados nas variáveis e funções da classe a qual eles pertencem, e não nas de outras 
classes. Quando um método usa métodos de acesso e de alteração de algum outro objeto para 
manipular os dados dentro deste objeto, o método inveja o escopo da classe daquele outro objeto. 
Ele queria estar dentro daquela outra classe de modo que pudesse ter acesso direto às variáveis 
que está manipulando. Por exemplo: 


public class HourlyPayCalculator ( 
public Money calculateWeeklyPay(HourlyEmployee e) ( 
int tenthRate - e.getTenthRate().getPennies(); 
int tenthsWorked = e.getTenthsWorked(); 
int straightTime - Math.min(400, tenthsWorked); 
int overTime - Math.max(0, tenthsWorked - 


straightTime); 
int straightPay - straightTime * tenthRate; 
int overtimePay - (int)Math. 
round(overTime*tenthRate*1.5); 


return new Money(straightPay + overtimePay); 
3 
{ 


O método calculateWeeklyPay consulta o objeto HourlyEmployee para obter os dados nos 
quais ele opera. Então, o método HourlyEmployee inveja o escopo de Hour lyEmployee. Ele 
“queria” poder estar dentro de HourlyEmployee. 

Sendo todo o resto igual, desejamos eliminar a Feature Envy (“inveja de funcionalidade”, 
tradução livre), pois ela expõe os componentes internos de uma classe à outra. De vez em quando, 
entretanto, esse é um mal necessário. Considere o seguinte: 


public class HourlyEmployeeReport ( 
private HourlyEmployee employee ; 


public HourlyEmployeeReport(HourlyEmployee e) ( 
this.employee = e; 
› 


String reportHours() { 
return String.format( 
"Name: $s\tHours:%d.%1d\n", 
employee.getName(), 
employee.getTenthsWorked()/10, 
employee.getTenthsWorked()$10); 


6. [Refatoracáo]. 
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} 


Está claro que o método reportHours inveja a classe HourlyEmployee. Por outro lado, não 
queremos que HourlyEmployee tenha de enxergar o formato do relatório. Mover aquela string 
de formato para a classe HourlyEmployee violaria vários princípios do projeto orientada a 
objeto”, pois acoplaria HourlyEmployee ao formato do relatório, expondo as alterações feitas 
naquele formato. 


G15: Parâmetros seletores 


Dificilmente há algo mais abominável do que um parâmetro false pendurado no final da 
chamada de uma função. O que ele significa? O que mudaria se ele fosse true? Não bastava 
ser difícil lembrar o propósito de um parâmetro seletor, cada um agrupa muitas funções em uma 
única. Os parâmetros seletores são uma maneira preguiçosa de não ter de dividir uma função 
grande em várias outras menores. Considere o seguinte: 


public int calculateWeeklyPay(boolean overtime) { 
int tenthRate - getTenthRate(); 
int tenthsWorked = getTenthsWorked(); 
int straightTime = Math.min(400, tenthsWorked); 
int overTime = Math.max(0, tenthsWorked - straightTime); 
int straightPay - straightTime * tenthRate; 
double overtimeRate = overtime ? 1.5 : 1.0 * tenthRate; 
int overtimePay - (int)Math.round(overTime*overtimeRate); 
return straightPay + overtimePay; 

А 


Você chama essa função com true se as horas extras forem pagas сото uma hora е meia а 
mais, e false se forem como horas normais. Já é ruim o bastante ter de lembrar o que 
calculateWeeklyPay (false) significa sempre que você a vir. Mas o grande problema de 
uma função como essa está na oportunidade que o autor deixou passar de escrever o seguinte: 


public int straightPay() { 
return getTenthsWorked() * getTenthRate(); 
> 


public int overTimePay() ( 
int overTimeTenths = Math.max(0, getTenthsWorked() - 400); 
int overTimePay = overTimeBonus(overTimeTenths); 
return straightPay() + overTimePay; 

) 


private int overTimeBonus(int overTimeTenths) ( 
double bonus = 9.5 * getTenthRate() * overTimeTenths; 
return (int) Math.round(bonus); 

H 


É claro que os seletores não precisam ser booleanos. Podem ser enums, inteiros ou outro tipo 
de parâmetro usado para selecionar o comportamento da função. De modo geral, é melhor ter 


7. Especificamente: o Principio da Kesponssbikdede Única, o Princípio de Aberta-Fechado e 0 Principio do Fecho Comum. Consulte [PPP] 
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muitas funções do que passar um código por parâmetro para selecionar o comportamento. 
G16: Propósito obscuro 


Queremos que o código seja o mais expressivo possível. Expressões contínuas, notação húngara 
e números mágicos são elementos que obscurecem a intenção do autor. Por exemplo, abaixo esta 
como poderia aparecer a função overTimePay: 


public int m otCalc() ( 
return iThsWkd * iThsRte * 
(int) Math.round(0.5 * iThsRte * 
Math.max(0, iThsWkd - 400) 


) 


Pequena e concisa como pode parecer, ela também é praticamente impenetrável. Vale a pena 
separar um tempo para tornar visível o propósito de nosso código para nossos leitores. 


G17: Responsabilidade mal posicionada 


Onde colocar o código é uma das decisões mais importantes que um desenvolvedor de software 
deve fazer. Por exemplo, onde colocar a constante P1? Na classe Math? Talvez na classe 
Trigonometry? Ou quem sabe na classe Circle? 

O princípio da surpresa mínima entra aqui. Deve-se substituir o código onde um leitor geralmente 
espera. A constante PI deve ficar onde estão declaradas as funções de trigonometria. A constante 
OVERTIME RATE deve ser declarada na função HourlyPayCalculator. 

Às vezes damos uma de “espertinhos” na hora de posicionar certa funcionalidade. Colocamo- 
la numa função que é conveniente para nós, mas não necessariamente intuitiva para o leitor. 
Por exemplo, talvez precisemos imprimir um relatório com o total de horas trabalhadas por um 
funcionário. Poderíamos somar todas aquelas horas no código que imprime o relatório, ou tentar 
criar um cálculo contínuo do total num código que aceite uma interação com os cartões de ponto. 
Uma maneira de tomar essa decisão é olhar o nome das funções. Digamos que nosso módulo de 
relatório possua uma função getTotalHours. Digamos também que esse módulo aceite uma 
interação com os cartões de ponto e tenha uma função saveTimeCard. Qual das duas funções, 
baseando-se no nome, indica que ela calcula o total? A resposta deve ser óbvia. 

Claramente, há, às vezes, questões de desempenho pelo qual se deva calcular o total usando-se os 
cartões de ponto em vez de fazê-lo na impressão do relatório. Tudo bem. mas os nomes das funções 
devem refletir isso. Por exemplo, deve existir uma função computeRunningTotalOfHours no 
módulo timecard. 


G18: Modo estático inadequado 
Math.max (double a, double b) é um bom método estático. Ele nào opera em só uma 


instância; de fato, seria tolo ter de usar Math () .max (a,b) ou mesmo a .max (b). 
Todos os dados que max usa vêm de seus dois parâmetros, e não de qualquer objeto “pertencente” 
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a ele. Sendo mais específico, há quase nenhuma chance de querermos que Math.max seja 
polifórmico. 
As vezes, contudo, criamos funções estáticas que não deveriam ser. Por exemplo, considere a função 


HourlyPayCalculator.calculatePay (employee, overtimeRate) . 


Novamente, pode parecer uma função estática lógica. Elanão opera em nenhum objeto em particular 
e obtém todos os seus dados a partir de seus parâmetros. Entretanto, há uma chance razoável de 
desejarmos que essa função seja polifórmica. Talvez desejemos implementar diversos algoritmos 
diferentes para calcular o pagamento por hora, por exemplo, OvertimeHourlyPayCalculator 
eStraightTimeHourlyPayCalculator. Portanto, neste caso, a função não deve ser estática, 
e sim uma função membro não estática de Employee. 

Em geral, deve-se dar preferência a métodos não estáticos. Na dúvida, torne a função não estática. 
Se você realmente quiser uma função estática, certifique-se de que não há possibilidades de você 
mais tarde desejar que ela se comporte de maneira polifórmica. 


G19: Use variáveis descritivas 


Kent Beck escreveu sobre isso em seu ótimo livro chamado Smalltalk Best Practice Patterns*, 
e mais recentemente em outro livro também ótimo chamado Implementation Patterns”. Uma 
das formas mais poderosas de tornar um programa legível é separar os cálculos em valores 
intermediários armazenados em variáveis com nomes descritivos. 

Considere o exemplo seguinte do FitNesse: 


Matcher match = headerPattern.matcheríline); 
if(match.find()) 
t 
String key - match.group(1); 
String value - match.group(2); 
headers.put(key.toLowerCase(), value); 
y 


O simples uso de variáveis descritivas esclarece que o primeiro grupo de comparacào (match 
group) é a chave (key), e que o segundo é o valor (value). 

É dificil fazer mais do que isso. Mais variáveis explicativas geralmente são melhores do que 
menos. É impressionante como um módulo opaco pode repentinamente se tornar transparente 
simplesmente ao separar os cálculos em valores intermediários bem nomeados. 


G20: Nomes de funções devem dizer o que elas fazem 


Veja este código: 


Date newDate = date.add(5); 


Você acha que ele adiciona cinco dias à data? Ou seria a semanas, ou horas? A instância date 
mudou ou a função simplesmente retornou uma nova Date sem alterar a antiga? 


3. [Beck97], p. 108. 
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Não dá para saber a partir da chamada o que a função faz. 

Se a função adiciona cinco dias à data e a altera, então ela deveria se chamar addDaysTo ou 
increaseByDays. Se, por outro lado, ela retorna uma nova data acrescida de cinco dias, mas 
não altera a instância date, ela deveria se chamar daysLater ou daysSince. 

Se você tiver de olhar a implementação (ou a documentação) da função para saber o que ela faz, 
então é melhor selecionar um nome melhor ou reorganizar a funcionalidade de modo que esta 
possa ser colocada em funções com nomes melhores. 


G21: Entenda o algoritmo 


Criam-se muitos códigos estranhos porque as pessoas não gastam tempo para entender o 
algoritmo. Elas fazem algo funcionar jogando estruturas if e flags, sem parar e pensar no que 
realmente está acontecendo. 

Programa geralmente é uma análise. Você acha que conhece o algoritmo certo para algo e, então, 
acaba perdendo tempo com ele e pincelando aqui e ali até fazê-lo “funcionar”. Como você sabe 
que ele “funciona”? Porque ele passa nos casos de teste nos quais você conseguiu pensar. 

Não há muito de errado com esta abordagem. De fato, costuma ser a única forma de fazer uma 
função funcionar como você acha que ela deva. Entretanto, deixar a palavra “funcionar” entre 
aspas não é o suficiente. 

Antes de achar que já terminou com uma função, certifique-se de que você entenda como ela 
funciona. Ter passado em todos os testes não basta. Você deve compreender 10 que a solução está 
correta. Geralmente, a melhor forma de obter esse conhecimento e entendimento é refatorar a 
função em algo que seja tão limpo e expressivo que fique óbvio que ela funciona. 


G22: Torne dependências lógicas em físicas 


Se um módulo depende de outro, essa dependência deve ser física, e não apenas lógica. O 
módulo dependente não deve fazer suposições (em outras palavras, dependências lógicas) sobre 
o módulo no qual ele depende. Em vez disso, ele deve pedir explicitamente àquele módulo todas 
as informações das quais ele depende. 

Por exemplo, imagine que você esteja criando uma função que imprima um relatório de texto 
simples das horas trabalhadas pelos funcionários. Uma classe chamada HourlyReporter junta 
todos os dados em um formulário e, então, o passa para HourlyReportFormatter imprimi-lo. 
Não estar certo se um algoritmo é adequado costuma ser um fato da vida. Não estar certo do que 
faz o seu código é simplesmente preguiça. 
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Listagem 17-1 
HourlyReporter.java 


public class HourlyReporter ( 
private HourlyReportFormatter formatter; 
private List«LineItem» page; 
private final int PAGE SIZE - 55; 


public HourlyReporter (HourlyPeportFormatter formatter) ( 
this.formatter - formatter 
page = new ArrayList«LineItem»i); 

public void generatereport (List<HouriyEmployee> em 
for (HourlyEmployee e : employees) { 

addLineItemToPage(e) ; 

if (page.size() == PAGE SIZE) 
printAndClearItemList[); 


) 
if (page.size() > 0j 


printAndClearitemList () ; 


private void printandClearitembist(i ( 
formatter. format (page) ; 
page.cleari); 

) 


private void addLineltemToPage (HourlyEmployee e) | 
LineItem item = new Lineltem(); 
cem.name 


item.hours 


item.tenths = e.getTenthsWorked() $ 10; 
page.add item 
} 


public class LineItem | 
public String name; 
public int hours; 
public int tenths; 

| 


Esse código possui uma dependência que não foi transformada em fisica. Você consegue enxergá- 
la? E a constante PAGE SIZE. Por que HourlyReporter deveria saber o tamanho da página? 
Isso deveria ser responsabilidade de HourlyReportFormatter. 

O fato de PAGE, SIZE estar declarada em HourlyReporter representa uma responsabilidade 
mal posicionada [G17] que faz HourlyReporter assumir que ele sabe qual deve ser o tamanho 
da página. Tal suposição é uma dependência lógica. HourlyReporter depende do fato de que 
HourlyReportFormatter pode lidar com os tamanhos 55 de página. Se alguma implementação 
de HourlyReportFormatter não puder lidar com tais tamanhos, então haverá um erro. 
Podemos tornar essa dependência fisica criando um novo método chamado getMaxPagesize () 
em HourlyReportFormatter. Então, HourlyReporter chamará a função em vez de usar a 
constante PAGE. SIZE. 


PO Ee ors So ЗР pn EP ERES 
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G23: Prefira polimorfismo a if...else ou switch...case 


Essa pode parecer uma sugestão estranha devido ao assunto do Capitulo 6. Afinal, lá eu disse 
que as estruturas switch possivelmente são adequadas nas partes do sistema nas quais a adição 
de novas funções seja mais provável do que a de novos tipos. 

Primeiro, a maioria das pessoas usa os switch por ser a solução por força bruta óbvia, e não por 
ser a correta para a situação. Portanto, essa heurística está aqui para nos lembrar de considerar o 
polimorfismo antes de usar um switch. 

Segundo, são relativamente raros os casos nos quais as funções são mais voláteis do que os tipos. 
Sendo assim, cada estrutura switch deve ser um suspeito. 

Eu uso a seguinte regra do “UM SWITCH”: Não pode existir mais de uma estrutura switch 
para um dado tipo de seleção. Os casos nos quais o switch deva criar objetos polifórmicos que . 
substituam outras estruturas switch no resto do sistema. 


G24: Siga as convenções padrões 


Cada equipe deve seguir um padrão de programação baseando-se nas normas comuns do 
mercado. Esse padrão deve especificar coisas como onde declarar instâncias de variáveis; 
como nomear classes, métodos e variáveis; onde colocar as chaves; e assim por diante. A 
equipe não precisa de um documento que descreva essas convenções, pois seus códigos 
fornecem os exemplos. 

Cada membro da equipe deve seguir essas convenções. Isso significa que cada um deve ser 
maduro o suficiente para entender que não importa onde você coloque suas chaves contanto 
que todos concordem onde colocá-las. 

Se quiser saber quais convenções си sigo, veja o código refatorado da Listagem B.7 (p. 394) 
até a B.14. 


G25: Substitua os números mágicos por constantes com nomes 


Essa é provavelmente uma das regras mais antigas em desenvolvimento de software. 
Lembro-me de tê-la lido no final da década de 1960 nos manuais de introdução de COBOL, 
FORTRAN e PL/1. De modo geral, é uma péssima ideia ter números soltos em seu código. 
Deve-se escondê-los em constantes com nomes bem selecionados. 

Por exemplo, o número 86.400 deve ficar escondido na constante SECONDS PER. DAY. Se 
você for imprimir 55 linhas por página, então a constante 55 deva ficar na constante LINES 
PER PAGE. 

Algumas constantes são tão fáceis de reconhecer que nem sempre precisam de um nome 
para armazená-las, contanto que sejam usadas juntamente com um código bastante auto- 
explicativo. Por exemplo: 


double milesWalked = feetWalked/5280.0; 


int dailyPay - hourlyRate * 8; 
double circumference - radius * Math.PI * 2; 


Realmente precisamos das constantes FEET PER MILE, WORK HOURS. PER DAY e TWO no 
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exemplo acima? Está óbvio que o último caso é um absurdo. Há algumas fórmulas nas quais 
fica melhor escrever as constantes simplesmente como números. Talvez você reclame do caso de 
WORK HOURS PER. DAY, pois as leis e convenções podem mudar. Por outro lado, aquela fórmula 
é tão fácil de ler com o 8 nela que eu ficaria relutante em adicionar 17 caracteres extras para o 
leitor. E no caso de FEET. PER MILE, o número 5280 é tão conhecido e exclusivo que os leitores 
reconheceriam mesmo se estivesse numa página sem contexto ao redor. 

Constantes como 3.141592653589793 também são tão conhecidas e facilmente reconhecíveis. 
Entretanto, a chance de erros é muito grande para deixá-las como números. Sempre que alguém 
vir 3.1415927535890793, saberão que é pi. e, portanto. não olharão com atenção. (Percebeu que 
um número está errado?) Também não queremos pessoas usando 3,14, 3.14159, 3,142, e assim 
por diante. Mas é uma boa coisa que Math. PT já tenha sido definida para nós. 

O termo “Número Mágico” não se aplica apenas a números, mas também a qualquer token 
(símbolos, termos, expressões, números, etc.) que possua um valor que não seja auto-explicativo. 
Por exemplo: 


assertEquals(7777, Employee.find(*John Doe").employeeNumber()); 


Há dois números mágicos nessa confirmação. Obviamente o primeiro é 7777, embora seu significado 
possa não-ser óbvio. O segundo é “John Doe”, e, novamente, o propósito não está claro. 
Acabou que “John Doe” é o nome do funcionário 47777 em um banco de dados de testes 
criado por nossa equipe. Todos na equipe sabem que ao se conectar a este banco de dados, ele 
ја possuirá diversos funcionários incluídos com valores e atributos conhecidos. Também acabou 
que “John Doe” representa o único funcionário horista naquele banco de dados. Sendo assim, 
esse teste deve ser: 


assertEquals( 
HOURLY EMPLOYEE ID, 
Employee.find(HOURLY EMPLOYEE NAME).employeeNumber()); 


G26: Seja preciso 


Esperar que a primeira comparação seja a única feita em uma consulta é ser ingênuo. Usar 
números de ponto flutuante para representar moedas é quase criminoso. Evitar gerenciamento 
de bloqueios e/ou transações porque você não acha que a atualização concorrente seja provável, 
é no mínimo desleixo. Declarar uma variável para ser uma ArrayList quando uma List é o 
suficiente, é totalmente constrangedor. Tornar protegidas por padrão todas as variáveis não 
é constrangedor o suficiente. 

Quando você toma uma decisão em seu código, certifique-se de fazê-la precisamente. Saiba por 
que a tomou e como você lidará com quaisquer exceções. Não seja desleixado com a precisão 
de suas decisões. Se decidir chamar uma função que retorne null, certifique-se de verificar por 
null. Se for consultar o que você acha ser o único registro no banco de dados, garanta que 
seu código verifique se não há outros. Se precisar lidar com concorrência, use inteiros” e lide 
apropriadamente com o arredondamento. Se houver a possibilidade de atualização concorrente. 
certifique-se de implementar algum tipo de mecanismo de bloqueio. 

Ambiguidades c imprecisão em códigos são resultado de desacordos ou desleixos. Seja qual for 
o caso, elas devem ser eliminadas. 


11. Ou. melhor ainda, uma classe Money que usc inteiros. 
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G27: Estrutura acima de convenção 


Insista para que as decisões do projeto baseiem-se em estrutura acima de convenção. Convenções 
de nomenclatura são boas, mas são inferiores às estruturas, que forçam um certo cumprimento. 
Por exemplo, switch...cases com enumerações bem nomeadas são inferiores a classes base 
com métodos abstratos. Ninguém é obrigado a implementar a estrutura switch...case da 
mesma forma o tempo todo: mas as classes base obrigam a implementação de todos os métodos 
abstratos das classes concretas. 


G28: Encapsule as condicionais 


A lógica booleana já é dificil o bastante de entender sem precisar vê-la no contexto de um if ou 
um while. Extraia funções que expliquem o propósito da estrutura condicional, 
Por exemplo: 


if (shouldBeDeleted(timer)) 
é melhor do que 


if (timer.hasExpired() && !timer.isRecurrent()) 


G29: Evite condicionais negativas 


É um pouco mais dificil entender condições negativas do que afirmativas. Portanto, sempre que 
possível, use condicionais afirmativas. Por exemplo: 


if (buffer.shouldCompact()) 
é melhor do que 


if (!buffer.shouldNotCompact()) 


G30: As funções devem fazer uma coisa só 


Costuma ser tentador criar funções que tenham várias seções que efetuam uma série de operações. 
Funções desse tipo fazem mais de uma coisa, e devem ser dividas em funções melhores, cada um 
fazendo apenas uma coisa. 

Por exemplo: 


public void pay() { 
for (Employee e : employees) ( 
if (e.isPayday()) { 
Money pay = e.calculatePay(); 
e.deliverPay(pay); 


$ 
} 
Esse pedaço de código faz três coisas. Ele itera sobre todos os funcionários, verifica se cada um 
deve ser pago e, então, paga o funcionário. Esse código ficaria melhor assim: 
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public void рау() { 
for (Employee e : employees) 
payTfNecessary(e); 
} 


private void payIfNecessary(Employee e) { 
if (e.isPayday()) 
calculateAndDeliverPay(e); 
} 
private void calculateandDeliverPay(Employee e) { 
Money pay = e.calculatePay(); 
e.deliverPay (pay); 


Cada uma dessas funções faz apenas uma coisa. (Consulte Faça apenas uma coisa na página 35.) 
G31: Acoplamentos temporários ocultos 


Acoplamentos temporários costumam ser necessários, mas não se deve ocultá-los. Organize os 
parâmetros de suas funções de modo que a ordem na qual são chamadas fique óbvia. 
Considere o seguinte: 


public class MoogDiver ( 
Gradient gradient; 
List<Spline> splines; 


public void dive(String reason) ( 
saturateGradient(); 
reticulateSplines(); 
diveForMoog(reason); 


) 


A ordem das trés funções é importante. Você deve saturar o gradiente antes de poder dispor 
em formato de redes (reticulate) as ranhuras (splines) e só então você pode seguir para o 
Moog (dive for moog). Infelizmente, o código não exige esse acoplamento temporário. 
Outro programador poderia chamar reticulateSplines antes de saturateGradient, gerando uma 
UnsaturatedGradientException. 

Uma solução melhor seria: 


public class MoogDiver { 
Gradient gradient; 
List<Spline> splines; 


public void dive(String reason) ( 
Gradient gradient - saturateGradient(); 
List<Spline> splines = reticulateSplines(gradient); 
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diveForMoog(splines, reason); 


H 


Isso expõe o acoplamento temporário ao criar um “bucket brigade"*1. Cada função produz um 
resultado que a próxima precisa, portanto não há uma forma lógica de chamá-los fora de ordem. 
Talvez você reclame que isso aumente a complexidade das funções, e você está certo. Mas 
aquela complexidade sintática extra expõe a complexidade temporal verdadeira da situação. 
Note que deixei as instâncias de variáveis. Presumo que elas sejam necessárias aos métodos privados 
na classe. Mesmo assim, mantive os parámetros para tornar explícito o acoplamento temporário. 


G32: Não seja arbitrário 


Tenha um motivo pelo qual você estruture seu código e certifique-se de que tal motivo seja 
informado na estrutura. Se esta parece arbitrária, as outras pessoas se sentirão no direito de 
alterá-la. Mas se uma estrutura parece consistente por todo o sistema, as outras pessoas irão usá- 
la e preservar a convenção utilizada. Por exemplo, recentemente eu fazia alterações ao FitNesse 
quando descobri que um de nossos colaboradores havia feito isso: 


public class AliasLinkWidget extends ParentWidget 
И 
public static class VariableExpandingWidgetRoot { 


H 


O problema era que VariableExpandingWidgetRoot não tinha necessidade para estar 
dentro do escopo de AliasLinkWidger. Ademais, outras classes sem relação usavam а 
AliasLinkWidget.VariableExpandingWidgetRoot. Essas classes não precisavam 
enxergar a AliasLinkWidget. 

Talvez o programador tenha jogado а VariableExpandingWidgetRoot dentro de 
AliasWidget por questão de conveniência. Ou talvez ele pensara que ela realmente precisava 
ficar dentro do escopo de Aliaswidget. Seja qual for a razão, o resultado acabou sendo 
arbitrário. Classes públicas que não são usadas por outras classes não podem ficar dentro de 
outra classe. A convenção é torná-las públicas no nível de seus pacotes. 


G33: Encapsule as condições de limites 


Condições de limite são difíceis de acompanhar. Coloque o processamento para elas em um 
único lugar. 

Não as deixe espalhadas pelo código. Não queremos um enxame de +1s e -1s aparecendo aqui e 
acolá. Considere o exemplo abaixo do FIT: 


if(level + 1 < tags.length) 
{ 
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parts = new Parse(body, tags, level + 1, offset + endTag); 
body - null; 
} 


Note que level+1 aparece duas vezes. Essa é uma condição de limite que deveria estar 
encapsulada dentro de uma variável com um nome ou algo como next Level. 


int nextLevel = level + 1; 
ifinextLevel < tags.length) 


parts = new Parse(body, tags, nextLevel, offset + endTag); 
body = null; 
} 


G34: Funções devem descer apenas um nível de 


As instruções dentro de uma função devem ficar todas no mesmo nível de , o qual deve ser 
um nível abaixo da operação descrita pelo nome da função. Isso pode ser o mais difícil dessas 
heurísticas para se interpretar e seguir. Embora a ideia seja simples o bastante, os seres humanos 
são de longe ótimos em misturar os níveis de . Considere, por exemplo, o código seguinte retirado 
do FitNesse: 


public String render() throws Exception 
{ 
StringBuffer html = new StringBuffer("<hr"); 
if(size > 0) 
html.append(* size=\""),append(size + 1).append(*\""); 
html.append(*»*); 
return html.toString(); 
) 


Basta analisar um pouco e você verá o que está acontecendo. Essa função constrói a tag 
HTML que desenha uma régua horizontal ao longo da página. A altura da régua é especificada 
na variável size. 

Leia o método novamente. Ele está misturando pelo menos dois niveis de . O primeiro é a noção 
de que uma régua horizontal (horizontal rule, daí a tag hr) possui um tamanho. O segundo é a 
própria sintaxe da tag HR. 

Esse código vem do módulo HruleWidget no FitNesse. Ele detecta uma sequência de quatro ou mais 
traços horizontais e a converte em uma tag HR apropriada. Quanto mais traços, maior o tamanho. 
Eu refatorei abaixo esse pedaço de código. Note que troquei o nome do campo size para refletir 
seu propósito real. Ele armazena o número de traços extras. 


public String render() throws Exception 
t 
HtmlTag hr = new HtmlTag("hr"); 
if (extraDashes » 0) 
hr.addAttribute("size*, hrSize(extraDashes)); 
return hr.html(); 
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private String hrSize(int height) 
{ 

int hrSize = height + 1; 

return String.format(“td”, hrSize); 
} 


Essa mudança separa bem os dois níveis de . A função render simplesmente constrói uma tag 
HR, sem ter de saber a sintaxe HTML da tag. 

O módulo Html Tag trata de todas as questões complicadas da sintaxe. 

Na verdade. ao fazer essa alteração. notei um pequeno erro. O código original não colocava uma 
barra na tag HR de fechamento, como o faria o padrão XHTML. (Em outras palavras, foi gerado 
«hr» em vez de «hr />.) O módulo Html Tag foi alterado para seguir o XHTML há muito tempo. 
Separar os níveis de é uma das funções mais importantes da refatoração, e uma das mais dificeis 
também. Como um exemplo, veja o código abaixo. Ele foi a minha primeira tentativa em separar 
os níveis de no HruleWidget . render method. 


public String render() throws Exception 


HtmlTag hr = new HtmlTag(*hr"); 
if (size > 0) ( 
hr.addAttribute(“size”, ""*(size*1)); 
} 
return hr.html(); 
) 


Meu objetivo, naquele momento, era criar a separacáo necessária para fazer os testes passarem. 
Isso foi fácil, mas fiquei com uma função que ainda tinha níveis de misturados. Neste caso, eles 
estavam na construção da tag HR e na interpretação e formatação da variável size. Isso indica 
ao dividir uma função em linhas de , você geralmente descobre novas linhas de que estavam 
ofuscadas pela estrutura anterior. 


G35: Mantenha os dados configuráveis em níveis altos 


Se você tiver uma constante, como um valor padrão ou de configuração. que seja conhecida e 
esperada em um nível alto de , nào a coloque numa função de nível baixo. Exponha a constante 
como parâmetro para tal função, que será chamada por outra de nível mais alto, Considere o 
código seguinte do FitNesse: 


public static void main(String[] args) throws Exception 
{ 
Arguments arguments = parseCommandLine(args); 


н: 


public class Arguments 
{ 
public static final String DEFAULT PATH = “."; 
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public static final String DEFAULT ROOT = *FitNesseRoot"; 
public static final int DEFAULT PORT - 80; 
public static final int DEFAULT VERSION DAYS - 14; 


} 


Os parâmetros na linha de comando são analisados sintaticamente na primeira linha executável 
do FitNesse. O valor padrão deles é especificado no topo da classe Argument. Não é preciso sair 
procurando nos níveis mais baixos do sistema por instruções como a seguinte: 


if (arguments.port == 0) // use 80 por padrao 


As constantes de configuração ficam em um nível muito alto e são fáceis de alterar. Elas são passadas 
abaixo para o resto do aplicativo. Os níveis inferiores não detêm os valores de tais constantes. 


G36: Evite a navegação transitiva 


De modo geral, não queremos que um único módulo saiba muito sobre seus colaboradores. Mais 
especificamente, se A colabora com в e B colabora com C, nào queremos que os módulos que 
usem A enxerguem C. (Por exemplo, não queremos a .getB() .getC() .doSomething();.) 
Isso às vezes se chama de Lei de Demeter. Os programadores pragmáticos chamam de "criar um 
código tímido""", Em ambos os casos, resume-se a se garantir que os módulos enxerguem apenas 
seus colaboradores imediatos, e não o mapa de navegação de todo o sistema. 

Se muitos módulos usam algum tipo de instrução a. getB() .getC(), então seria dificil alterar 
o projeto e a arquitetura para introduzir um Q entre B e C. Seria preciso encontrar cada instância 
de a.getB() .getC() e converter para a.getB() .getQ() .gecC(). 

É assim que as estruturas se tornam rígidas. Módulos em excesso enxergam demais sobre a 
arquitetura. 

Em vez disso, queremos que nossos colaboradores imediatos ofereçam todos os serviços de 
que precisamos. Não devemos ter de percorrer a planta do sistema em busca do método que 
desejamos chamar, mas simplesmente ser capaz de dizer: 


meuColaborador.facaAlao(). 
Java 


J1: Evite longas listas de importação usando wildcards 
(caracteres curinga) 


Se vocé usa duas ou mais classes de um pacote, entào importe o pacote todo usando 


import package.*; 
Listas longas de import intimidam o leitor. Nào queremos amontoar o topo de nossos módulos 
com 80 linhas de import. Em vez disso, desejamos que os import sejam uma instrução concisa 
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sobre os pacotes que usamos. 

Importações específicas são dependências fixas, enquanto importações com caracteres curingas 
não são. Se você não importar uma classe especificamente, então ela deve existir. Mas se você 
importa um pacote com um caractere curinga (wildcards), uma determinada classe não precisa 
existir. A instrução import simplesmente adiciona o pacote ao caminho de busca na procura por 
nomes. Portanto, os import nào criam uma dependência real, e, portanto, servem para manter os 
módulos menos acoplados. 

Há vezes nas quais a longa lista de import específicos pode ser útil. Por exemplo, se estiver 
lidando com código legado e deseja descobrir para quais classes você precisa para construir stubs 
(objetos que criam simulam um ambiente real para fins de testes) ou mocks (objetos similares 
que também analisam chamadas feitas a eles e avaliam a precisão delas), percorrer pela lista 
e encontrar os nomes verdadeiros de todas aquelas classes e, então, criar os stubs adequados. 
Entretanto, esse uso de import específicos é muito raro. Ademais. a maioria das IDEs modernas 
lhe permitem converter instruções import com caracteres curinga em um único comando. 
Portanto, mesmo no caso do código legado. é melhor importar usando caracteres curinga. 
Import com caracteres curinga pode às vezes causar conflitos de nomes e ambiguidades. Duas classes 
com o mesmo nome. mas em pacotes diferentes, precisam ser importadas especificamente, ou pelo 
menos limitada especificamente quando usada. Isso pode ser chato, mas é raro o bastante para que 
o uso de import com caracteres curinga ainda seja melhor do que importações específicas. 


J2: Não herde as constantes 


Já vi isso várias vezes e sempre faço uma careta quando vejo. Um programador coloca algumas 
constantes numa interface e, então, ganha acesso a elas herdando daquela interface. 
Observe o código seguinte: 


public class HourlyEmployee extends Employee ( 
private int tenthsWorked; 
private double hourlyRate; 
public Money calculatePay() ( 
int straightTime = Math min(tenthsWorked, TENTHS PER. 


WEEK); 
int overTime = tenthsWorked - straightTime; 
return new Money( 
hourlyRate * (tenthsWorked + OVERTIME RATE * 
overTime) 


de 
} 


} 


De onde vieram as constantes TENTHS_PER_WEEK ¢ OVERTIME_RATE? Devem ter vindo da 
classe Employee; então. vamos dar uma olhada: 
public abstract class Employee implements PayrollConstants ( 
public abstract boolean isPayday(); 
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public abstract Money calculatePay(); 
public abstract void deliverPay(Money pay): 
} 


Não, não está lá. Mas onde então? Leia atentamente а classe Employee. Ela implementa 
PayrollConstants. 


public interface PayrollConstants ( 
public static final int TENTHS PER WEEK - 400; 
public static final double OVERTIME RATE - 1.5: 


Y 


Essa é uma prática horrível! As constantes estão escondidas no topo da hierarquia de herança. 
Eca! Não use a herança como um meio para burlar as regras de escopo da linguagem. Em vez 
disso, use um import estático. 


import static PayrollConstants.*; 


public class HourlyEmployee extends Employee { 
private int tenthsWorked; 
private double hourlyRate; 
public Money calculatePay() ( 
int straightTime = Math.min(tenthsWorked, TENTHS. PER 


WEEK); 
int overTime = tenthsWorked - straightTime; 
return new Money( 
hourlyRate * (tenthsWorked + OVERTIME RATE * 
overTime) 


Nu 
) 


) 
J3: Constantes versus enum 


Agora que os enum foram adicionados à linguagem (Java 5), use-os! Nào fique usando o truque 
antigo de public static final int. Pode-se perder o significado dos int, mas nào dos 
enum, pois eles pertencem a uma enumeração que possui nomes. 

Além do mais, estudo cuidadosamente a sintaxe para os enum. Eles podem ter métodos e campos, o 
que os torna ferramentas muito poderosas que permitem muito mais expressividade e flexibilidade 
do que os int. Considere а variação abaixo do código da folha de pagamento (payroll). 


public class HourlyEmployee extends Employee ( 
private int tenthsWorked; 
HourlyPayGrade grade; 


public Money calculatePay() { 
int straightTime - Math.min(tenthsWorked, TENTHS PER. 
WEEK); 
int overTime - tenthsWorked - straightTime; 
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return new Money( 
grade.rate() * (tenthsWorked + OVERTIME RATE * 
overTime) 
); 


} 
› 


public enum HourlyPayGrade ( 
APPRENTICE ( 
public double rate() ( 
return 1.0; 
) 
2, 
LEUTENANT. JOURNEYMAN ( 
public double rate() ( 
return 1.2; 
) 
}, 
JOURNEYMAN { 
s public double rate() { 
return 1.5; 
} 
}, 
MASTER ( 
public double rate() ( 
return 2.0; 
) 


}; 


public abstract double rate(); 


) 
Nomes 


М1: Escolha nomes descritivos 


Não se apresse ao escolher um nome. Certifique-se de que ele seja descritivo. Lembre-se de que 
os sentidos tendem a se perder conforme o software evolui. Portanto, reavalie frequentemente a 
adequação dos nomes que você escolher. 

Essa não é apenas uma recomendação para lhe “satisfazer”. Nomes em softwares são 90% responsáveis 
pela legibilidade do software. Você precisa tomar seu tempo para escolhê-los sabiamente e mantê-los 
relevantes. Nomes são muito importantes para serem tratados de qualquer jeito. 

Considere o código abaixo. O que ele faz? Se eu lhe mostrasse o código com nomes bem 
escolhidos. ele faria sentido para você, mas como está abaixo, é apenas um emaranhado de 
símbolos e números mágicos. 


public int x() ( 
int q = 0; 
int z 0; 


ua 
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р) 
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for (int kk = 0; kk < 10; kk++) ( 
if (1[21] 10) 


q += 10 + (liz + 1] + Ц2 + 2]); 


else if (l(z] + l[z + 1] == 10) 


10 + l[z + 2]; 
2; 


liz] + liz + 1]; 
ЕЗ 


return q; 


Aqui está o código da forma como deveria ser. Na verdade, esse pedaço está menos completo 
do que o acima, Mesmo assim você pode entender imediatamente o que ele tenta fazer, e muito 
provavelmente até mesmo criar as funções que faltam bascando-se no que você compreendeu. 
Os números não são mais mágicos, e a estrutura do algoritmo está claramente descritiva. 


public int score() ( 


} 


int score = 0; 
int frame = 0; 
for (int frameNumber = 0; frameNumber < 10; frameNumber++) { 
if (isStrikeiframe)) ( 
score 10 + nextTwoBallsForStrike(frame); 
frame += 1; 
] else if (isSpare(frame)) ( 
score += 10 + nextBallForSpare(frame); 
frame += 2; 
) else ( 
score += twoBallsInFrame(frame); 
frame += 2; 


3 
1 
return score; 


O poder de selecionar cuidadosamente os nomes é que eles enchem a estrutura do código com 
descrições. Isso faz com que os leitores saibam o que esperar das outras funções no módulo. Só 
de olhar o código acima, você pode inferir a implementação de isStrike(). Quando você ler 
o método isStrike, ele será “basicamente o que você esperava”. 


private boolean isStrike(int frame) ( 


) 


return rolls[frame] -- 10; 


Nomes 307 


N2: Escolha nomes no nível apropriado de abstração 


Não escolha nomes que indiquem a implementação, mas nomes que reflitam o nível de da classe 
ou função na qual você está trabalhando. Essa tarefa é árdua. Novamente, as pessoas são muito 
boas em misturar níveis de . Cada vez que você analisa seu código, provavelmente encontrará 
alguma variável nomeada bascando-se em um nível muito baixo. Você deve aproveitar a chance 
с trocar aqueles nomes quando os encontrar. Tomar o código legivel requer dedicação a um 
aperfeiçoamento constante. Considere a interface Modem abaixo: 


public interface Modem ( 
boolean dial(String phoneNumber); 
boolean disconnect(); 
boolean send(char c); 
char recv(); 
String getConnectedPhoneNumber(); 
H 


À primeira vista, tudo parece bem. As fungóes parecem adequadas. Na verdade, para muitos 
aplicativos elas sào. Mas. agora, considere um aplicativo com alguns modens que nào se conectem 
por discagem. Em vez disso, eles ficam sempre conectados juntos por meio de fios (pense em 
modens a cabo que oferecem acesso à Internet à maioria das casas atualmente). Talvez alguns se 
conectem enviando o número de uma porta para um switch em uma conexão USB. Obviamente, 
a noção de números de telefones está no nível errado de . Uma melhor estratégia de nomenclatura 
para este cenário seria: 


public interface Modem ( 
boolean connect (String connectionLocator); 
boclean disconnect(); 
boolean send(char c); 
char recv(); 
String getConnectedLocator(); 
) 


Agora, os nomes nào se restringem aos nümeros de telefones. Eles ainda podem ser desse tipo, 
mas também podem usar outro tipo de conexão. 


N3: Use uma nomenclatura padrão onde for possível 


Nomes são mais fáceis de entender se baseados numa convenção ou uso já existente, Por exemplo, 
se estiver usando o padrão DECORATOR, você deve usar a palavra DECORATOR nos nomes das 
classes que o usam. Por exemplo, AutoHangupModemDecorator deve ser o nome de uma classe 
que “decora” um Modem com à capacidade de desligar automaticamente ao fim da sessão. 

Os padrões são apenas um tipo de padrão. Em Java, por exemplo, as funções que convertem 
objetos em representações de string costumam se chamar toString. É melhor seguir convenções 
como essas do que inventar a sua própria. 

Equipes frequentemente inventarão seus próprios sistemas de padrões de nomes para um projeto 
em particular. 


REN LLLA 
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Eric Evans se refere a isso como uma linguagem generalizada para o projeto". Seu código deve 
usar abundantemente os termos a partir dessa linguagem. Em suma, quanto mais você puder usar 
nomes que indiquem significados especiais relevantes ao seu projeto, mais fácil ficará para os 
leitores saberem sobre o que se trata seu código. 


N4: Nomes não ambíguos 


Escolha nomes que não deixem as tarefas de uma função ou variável ambíguas. Considere o 
exemplo seguinte do FitNesse: 


private String doRename() throws Exception 
t 
if(refactorReferences) 
renameReferences(); 
renamePage(); 
pathToRename.removeNameFromEnd(); 
pathToRename.addNameToEnd(newName); 
return PathParser.render(pathToRename); 
} 


O nome dessa função não diz o que a função faz, exceto em termos vagos. Isso foi enfatizado 
pelo fato de que há uma função chamada renamePage dentro da função chamada doRename! O 
que os nomes lhe dizem sobre a diferença entre as duas funções? Nada. 

Um nome melhor para aquela função seria renamePage AndOptionally AllReferences. Pode 
parecer longo, e é, mas ela só é chamada a partir de um local no módulo, portanto é um valor 
descritivo que compensa o comprimento. 


NS: Use nomes longos para escopos grandes 


O comprimento de um nome deve estar relacionado com o do escopo. Vocé pode usar nomes 
de variáveis muito curtos para escopos minúsculos. Mas para escopos grandes, devem-se usar 
nomes extensos. 

Nomes de variáveis como i e j são bons se seu escopo tiver cinco linhas apenas. Considere o 
pedaço de código abaixo do antigo padrão “Bowling Game” (jogo de boliche). 


private void rollMany(int n, int pins) 
( 


for (int i=0; i<n; i++) 
g.roll(pins); 
) 


Está perfeitamente claro e ficaria ofuscado se a variável i fosse substituída por algo importuno, como 
rollCount. Por outro lado, variáveis e funções com nomes curtos perdem seus sentidos em distâncias 
longas. Portanto, quanto maior o escopo do nome, maior e mais preciso o nome deve ser. 


N6: Evite codificações 
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Não se devem codificar nomes com informações sobre о tipo ou o escopo. Prefixos, como т ou 
f, são inúteis nos ambientes de hoje em dia. E codificações em projetos e/ou subsistemas, como 
siv (para sistema de imagem visual), são redundantes e distrativos. Novamente, os ambientes 
atuais fornecem todas essas informações sem precisar distorcer os nomes. Mantenha seus nomes 
livres da poluição húngara. 


М7: Nomes devem descrever os efeitos colaterais 


Nomes devem descrever tudo o que uma função, variável ou classe é ou faz. Não oculte os 
efeitos colaterais com um nome. Não use um simples verbo para descrever uma função que faça 
mais do que uma mera ação. Por exemplo, considere o código abaixo do TestNG: 

public ObjectOutputStream getOos() throws IOException ( 

if (m oos == null) ( 

m oos = new ObjectOutputStream(m socket.getOutputStream()): 


return m oos; 


) 


Essa função faz um pouco mais além de pegar um “ооз”; ela cria о “ооз” se ele não tiver sido 
criado ainda. Logo, um nome melhor seria createOrReturnOos. 


Testes 

Т1: Testes insuficientes 

Uma coleção de testes deve ter quantos testes? Infelizmente, a medida que muitos programadores 
usam é “Parece que já está bom”. Uma coleção de testes deve testar tudo que pode vir a falhar. 
Os testes são insuficientes enquanto houver condições que não tenham sido exploradas pelos 
testes ou cálculos que não tenham sido validados. 

T2: Use uma ferramenta de cobertura! 

Ferramentas de cobertura informam lacunas em sua estratégia de testes. Elas facilitam o encontro de 
módulos, classes e funções que são testados de modo insuficiente. A maioria das IDEs lhe dão uma 
indicação visual, marcando com verde as linhas que são cobertas pelos testes e de vermelho as que 
não são. Isso agiliza e facilita encontrar instruções i f e catch cujos corpos não foram verificados. 
T3: Não pule testes triviais 

Eles são fáceis de criar e seu valor de documentação é maior do que o custo de produzi-los. 


T4: Um teste ignorado é uma questão sobre uma ambiguidade 


Nós, às vezes, não estamos certos sobre um detalhe de comportamento devido à falta de clareza 
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dos requisitos. Podemos expressar nossa questão sobre os requisitos como um teste que é 
posto como comentário que é anotado com um @Ignore. O que você escolher dependerá se a 
ambiguidade é sobre algo que deva ou não compilar. 


T5: Teste as condições de limites 


Dê atenção especial aos testes de condições de limites. Geralmente, entendemos a parte central 
de um algoritmo. mas erramos sobre seus limites. 


T6: Teste abundantemente bugs próximos 


Bugs tendem a se reunir. Quando encontrar um bug numa função, é sábio fazer um teste exaustivo 
nela. Provavelmente você verá que o bug não estava só. 


T7: Padrões de falhas são reveladores 


De vez em quando, você pode diagnosticar um problema ao encontrar padrões na forma pela 
qual os casos de teste falharam. 

Esse é outro argumento para tornar os casos de teste os mais completos possíveis. Eles, quando 
ordenados de uma maneira lógica, expõem os padrões. 

Como um exemplo simples, suponha que você percebeu que todos os testes com uma entrada 
maior do que cinco caracteres tenham falhado? Ou e se um teste que passasse um número 
negativo para o segundo parâmetro de uma função falhasse? Às vezes, apenas ver o padrão 
de linhas vermelhas e verdes no relatório dos testes é o suficiente para soltar um “Arrá!” que 
leva à solução. Volte à página 267 para ver um exemplo interessante sobre isso no exemplo do 
SerialDate. 


Т8: Padrões de cobertura de testes podem ser reveladores 


Analisar o código que é ou nào executado pelos testes efetuados dá dicas do porqué de os testes 
que falharam estào falhando. 


T9: Testes devem ser rápidos 


Um teste lento é um que não será rodado. Quando as coisas ficam apertadas, são os testes lentos 
que serão descartados da coleção. Portanto, faça o que puder para manter seus testes rápidos. 


Conclusão 


Mal poderíamos dizer que esta lista de heurísticas e odores esteja completa. De fato, não estou 
certo se ela jamais estará. Mas, talvez, a plenitude não deva ser o objetivo, pois o que a lista 
realmente faz é dar um valor ao sistema. 

Na verdade, o sistema de valores tem sido o objetivo, e o assunto deste livro. Não se cria um 
código limpo seguindo uma série de regras. Você não se torna um especialista na arte de softwares 


Apêndice A 


Concorrência II 


por Brett L. Schuchert 


Este apêndice é uma extensão do capítulo Concorrência da página 177. E foi escrito com uma 
série de tópicos independentes e, possivelmente, você poderá lê-lo em qualquer ordem devido a 
alguns assuntos repetidos entre as seções. 


Exemplo de cliente/servidor 


Imagine um aplicativo do tipo cliente/servidor. Um servidor fica escutando um socket à espera 
que um cliente se conecte. Este se conecta e envia um pedido. 


O servidor 


A seguir está uma versão simplificada de um aplicativo servidor. O código completo para este 
exemplo começa na página 343, Cliente/sevidor sem threads. 


ServerSocket serverSocket = new ServerSocket (8009); 


while (keepProcessing) ( 
try { 
Socket socket = serverSocket.accept(); 
process(socket); 
} catch (Exception e) { 
handle(e); 
} 
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Este simples aplicativo espera por uma conexão, processa uma mensagem que chega e, então, 
espera novamente pelo pedido do próximo cliente. Abaixo está o código do cliente que se conecta 
a esse servidor: 


private void connectSendReceive(int i) ( 

try { 
Socket socket = new Socket("*localhost", PORT); 
MessageUtils.sendMessage(socket, Integer.toString(i)); 
MessageUtils.getMessage(socket); 
socket.close(); 

) catch (Exception e) ( 
e.printStackTrace(); 


3 


) 


Qual o nivel de desempenho entre esse cliente/servidor? Podemos descrevé-lo formalmente? 
A seguir está um teste que confirma se o desempenho é “aceitável”: 


@Test(timeout = 10000) 


public void shouldRunInUnderl0Seconds() throws Exception { 
Thread[] threads = createThreads(); 
startAllThreadsw(threads); 
waitForAllThreadsToFinish(threads); 


) 


A fim de manter o exemplo simples, deixamos configuração de fora (veja o ClienteTest.java. na 
página 344). Esse teste confirma se ele deve completar dentro de 10.000 milissegundos. 

Esse é um exemplo clássico de validação da taxa de transferência de dados de um sistema. Esse 
deve completar uma série de pedidos do cliente em dez segundos. Enquanto o servidor puder 
processar cada pedido individualmente a tempo, o teste passará. 

O que acontece se ele falhar? O limite de desenvolver um tipo de loop de transmissáo por 
solicitação é que nào há muito o que fazer dentro de uma única thread para agilizar este código. 
Usar múltiplas threads resolverá o problema? Talvez, mas precisamos saber onde está sendo 
desperdiçado tempo. Há duas possibilidades: 


+ E/S—usar um socket, conectar-se a um banco de dados, esperar pela troca com a memória 
virtual e assim por diante. 


* Processador—cálculos numéricos, processamento de expressões regulares, coleta de lixo e 
assim por diante. 


Os sistemas tipicamente possuem um pouco de cada, mas para uma dada operação tende a se usar 
apenas uma das duas. Se o código for baseado no processador, mais hardwares de processamento 
podem melhorar a taxa de transferência de dados, fazendo nossos testes passarem. Mas só que há 
tantos ciclos de CPU disponíveis de modo que adicionar threads a um problema baseando-se o 
processador não o tornará mais rápido. Por outro lado, se o processo for baseado em E/S, então 
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a concorrência pode aumentar com eficiência. 
Quando uma parte do sistema está esperando por uma E/S, outra parte pode usar esse tempo de 
espera para processar outra coisa, tornando o uso da CPU disponível mais eficiente. 


Adição de threads 


Agora vamos prever que o teste de desempenho falhe. Como podemos melhorar a taxa de 
paste de dados de modo que ele passe? Se o método do processo do servidor for bascado em 
„ então há uma maneira de fazer o servidor usar threads (apenas mude a processMessage): 


void process(final Socket socket) ( 
if (socket == null) 
return; 
Runnable clientHandler = new Runnable() ( 
public void run() ( 
try ( 


String message - MessageUtils. 
getMessage (socket); 
MessageUtils.sendMessage(socket, "Processed: 
~ + message); 
closeIgnoringException(socket); 
} catch (Exception e) { 
e.printStackTrace(); 
} 
) 
x 
Thread clientConnection - new Thread(clientHandler); 
clientConnection.start(); 
} 


Assuma que essa mudança faça o teste passar’; o código está completo, certo? 
Observações do servidor 


O servidor atualizado completa o teste com êxito em um segundo. Infelizmente, essa solução é 
um pouco ingênua e adiciona alguns problemas novos. 

Quantas threads nosso servidor poderia criar? O código não estabelece limites, portanto 
poderiamos normalmente alcançar o limite imposto pela Java Virtual Machine (JVM). Para 
muitos sistemas simples, isso talvez satisfaça. Mas e se o sistema suportar muitos usuários numa 
rede pública? Se muitos se conectarem ao mesmo tempo, o sistema pode travar. 

Mas deixe de lado o problema de comportamento por agora. A solução apresentada possui 
problemas de limpeza e estrutura. Quantas responsabilidades o código do servidor pode ter? 


* Gerenciamento de conexão com o socket 
* Processamento do cliente 

* Diretrizes para uso de threads 

* Diretrizes para desligamento do servidor 
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Infelizmente, todas essas responsabilidades ficam na função process. Ademais, o código 
mistura tantos níveis diferentes de . Sendo assim, por menor que esteja a função. ela precisa ser 
dividida. 

O servidor possui diversas razões para ser alterado; entretanto, isso violaria o Princípio da 
Responsabilidade Unica. Para manter limpos sistemas concorrentes, o gerenciamento de threads 
deve ser mantido em poucos locais bem controlados. Além do mais, qualquer código que gerencie 
threads só deva fazer essa tarefa. Por quê? Só pelo fato de que rastrear questões de concorrência 
é árduo o bastante sem ter de lidar ao mesmo tempo com outras questões não relacionadas à 
concorrência. 

Se criarmos uma classe separada para cada responsabilidade listada acima, incluindo uma para 
o gerenciamento de threads, então quando mudarmos a estratégia para tal gerenciamento, a 
alteração afetará menos o código geral e não poluirá as outras responsabilidades. Isso também 
facilita muito testar todas as outras responsabilidades sem ter de se preocupar com o uso de 
threads. Abaixo está uma versão atualizada que faz justamente isso: 


public void run() ( 
while (keepProcessing) ( 
try { 
ClientConnection clientConnection 
= connectionManager.awaitClient(); 
ClientRequestProcessor requestProcessor 
= new ClientRequestProcessor(clientConnectio 
п); 
clientScheduler.schedule(requestProcessor); 
) catch (Exception e) ( 
e.printStackTrace(); 
) 
} 
connectionManager.shutdown(); 


} 


Agora, se houver problemas de concorrência, só haverá um lugar para olhar, pois tudo relacionado 
a threads está num único local, em clientScheduler. 


public interface ClientScheduler ( 
void schedule(ClientRequestProcessor requestProcessor); 
} 


E facil implementar a diretriz atual: 


public class ThreadPerRequestScheduler implements ClientScheduler { 
public void schedule(final ClientRequestProcessor 
requestProcessor) { 
Runnable runnable = new Runnable() { 
public void runi) { 
requestProcessor.process(); 
) 
Thread thread - new Thread(runnable); 
thread.start(); 
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Ter isolado todo o gerenciamento de threads num único lugar facilitou bastante a alteração 
do modo como controlamos as threads. Por exemplo, mover o framework Executor do Java 5 
envolve criar uma nova classe e inseri-la no código (Listagem A.1). 


Conclusão 


Apresentar concorrência neste exemplo em particular demonstra uma forma de melhorar a taxa de 
transferência de dados de um sistema e de validar aquela taxa por meio de um framework de teste. 
Centralizar todo o código de concorrência em um pequeno número de classes é um exemplo da 
aplicação do Princípio da Responsabilidade Única. Neste caso de programação concorrente, isso 
se torna especialmente importante devido à sua complexidade. 


Caminhos possíveis de execução 


Revise o método incrementValue — método em Java de apenas uma linha sem iteração ou 
ramificação, 
public class IdGenerator ( 
int lastIdUsed; 


public int incrementvalue() ( 
return ++lastIdUsed; 
) 


} 


Ignore o excesso de inteiros e assuma que apenas uma thread possua acesso a uma única instância 
de IdGenerator. Neste caso, só há um caminho de execução e um resultado garantido: 


+ O valor retornado é igual ao valor de lastldUsed, e ambos estão uma unidade maior do que 
estavam antes de chamar o método. 


Listagem A-1 
ExecutorClientScheduler. java 


java.util.concurrent.Executor; 
t java-util.concurrent .Executors; 


c class ExecutorClientScheduler implements ClientScheduler 
cutor executor; 


public ExecutorClientScheduler(int availableThreads) { 
executor = Executors.newFixedThreadPool (availableThreads) ; 
i 


public void schedule(final ClientRequestProcessor requestProcessor) 
Runnable runnable = new Runnable() { 
public void run(j ( 


request Processor .process () ; 


}; 
executor execute (runnable) ; 
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O que acontece se usarmos duas threads e deixar o método inalterado? Quais os possíveis 
resultados se cada thread chamar incrementValue uma vez? Haverá quantos caminhos de 
execução possíveis? Primeiro, os resultados (assuma que lastldUsed comece com o valor 93): 


* Thread 1 recebe 94, thread 2 recebe 95 e last IdUsed agora é 95. 
* Thread | recebe 95. thread 2 recebe 94 e last IdUsed agora é 95. 
* Thread 1 recebe 94, thread 2 recebe 94 e last IdUsed agora é 94. 


O resultado final, mesmo que surpreendente, é possível. A fim de vermos como, precisamos 
entender a quantidade de caminhos possíveis de execução e como a Java Virtual Machine 
оз executa, 


Quantidade de caminhos 


Para cálculo do número de caminhos possíveis de execução, começaremos com o Bytecode 
gerado. A única linha em Java (return ++lastIdUsed; ) retoma oito instruções em bytecode. 
É possível para as duas threads intercalarem a execução das oito instruções do modo como um 
embaralhador de cartas faz na hora de embaralhar”. Mesmo com apenas oito cartas em cada mão, 
há uma quantidade considerável de resultados distintos. 

Para este caso simples de N instruções numa sequência, sem loop ou condicionais e sem T 
threads, a quantidade total de caminhos possíveis de execução é igual a 


(NT)! 
NT 
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Para nosso simples caso de uma linha de código Java, que equivale a oito linhas de bytecode e 
duas threads, o número total de caminhos possíveis de execução é de 12.870. Se last IdUsed 
for do tipo long, então cada leitura/escrita se torna duas operações em vez de uma, e o número 
possível de combinações se torna 2,704,156. 

O que acontece se fizermos uma alteração neste método? 


public synchronized void incrementValue() ( 
**lastldUsed; 
) 


A quantidade de caminhos possíveis de execução se torna dois para duas threads e N! no caso geral. 


Indo mais a fundo 


E o resultado surpreendente de que duas threads podiam ambas chamar o método uma vez (antes 
de adicionarmos synchronized) e obter o mesmo resultado numérico? Como isso pode ser 
possível? Calma, uma coisa de cada vez! 

O que é uma operação atômica? Podemos definir uma operação atômica como qualquer operação 
que seja interrompivel. Por exemplo, no código seguinte, linha 5, em que lastid recebe 0, é 
considerada uma operação atômica, pois segundo o modelo Java Memory, a atribuição de a um 
valor de 32 bits é interrompivel. 


01: public class Example ( 
02: int lastld; 


04: public void resetId() ( 
05: value - 0; 


320 Apéndice A: Concorrência II 


06: } 

07: 

08: public int getNextId() { 
09: ++value; 

£02) 1 

11: 


O que acontece se mudarmos o tipo de lastId de int para long? A linha 5 ainda será atómica? Nào 
de acordo com a especificação da JVM. Poderia ser atômica em um processador em particular, 
mas segundo a especificação da JVM, a atribuição a qualquer valor de 64 bits requer duas de 
32 bits. Isso significa que entre a primeira atribuição de 32 bits e a segunda também de 32 bits, 
alguma outra thread poderia se infiltrar e alterar um dos valores. 

E o operador de pré-incremento, ++, na linha 9? Ele pode ser interrompido, logo, ele não é 
atômico. Para entender, vamos revisar detalhadamente o bytecode de ambos os métodos. 

Antes de prosseguirmos, abaixo há três definições que serão importantes: 


* Quadro (frame) —toda chamada de método querer um quadro, que inclui o endereço de 
retorno, qualquer parâmetro passado ao método e as variáveis locais definidas no método. 
Essa'é uma técnica padrão usada para declarar uma pilha de chamadas usada pelas linguagens 
atuais, permitindo chamadas recursivas e funções/métodos básicos. 

+ Variável local —qualquer variável declarada no escopo do método. Todos os métodos não 
estáticos têm pelo menos uma variável this, que representa o objeto em questão — aquele que 
recebeu a mensagem mais recente (na thread em operação) — que gerou a chamada do método. 
+ Pilha de operadores —muitas das instruções na JVM recebem parâmetros, que ficam 
armazenados na pilha de operadores. A pilha é uma estrutura de dados do tipo LIFO (Last In, 
First Out, ou último a entrar, primeiro a sair). 


A seguir está o bytecode gerado para reset Id(): 


Mnemónica Descricào Pilha de operadores depois 
ALOAD 0 Coloca a 0o variável na pilha de | This 

operadores. O que é a 0o variável? É a 
this., o objeto atual. Quando o método 
é invocado, o receptor da mensagem 
— uma instância de Example — foi 
inserido no array de variáveis locais do 
quadro (frame) criado para a chamada 
do método. Essa é sempre a primeira 
variável colocada em cada instância 
do método. 

ICONST 0 Coloca o valor constante 0 na pilha de | this, 0 
operadores. this, 0 
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PUTFIELD Armazena o valor no topo da pilha | <empty> 
lastid (que é 0) no valor do campo do objeto 
referido por referência do objeto um a 
partir do topo da pilha, this. 


Essas três instruções são certamente atômicas, pois, embora a thread que as executa pudesse ser 
interrompida após qualquer uma delas, outras threads não poderão tocar nas informações para a 
instrução PUTFIELD (o valor constante 0 no topo da pilha e a referência para este um abaixo do 
topo, juntamente com o valor do campo). 

Portanto, quando ocorrer a atribuição, garantimos que o valor O seja armazenado no valor do 
campo. A operação é atômica. Todos os operadores lidam com informações locais ao método, 
logo não há interferência entre múltiplas threads. 

Sendo assim, se essas três instruções forem executadas por dez threads, haverá 4.38679733629e+24 
combinações. Mas como só existe um resultado possível as diferentes combinações são 
irrelevantes. Neste caso, acontece que o mesmo resultado é certo para o tipo long também. Por 
quê? Todas as dez threads atribuem um valor constante. Mesmo se intercalassem entre si, O 
resultado final seria o mesmo. 

Com a operação ++ no método getNext Id. haverá problemas. Suponha que last Id seja 42 no 
início deste método. A seguir está o bytecode gerado para este novo método: 


Mnemónica Descrição Pilha de operadores depois 
ALOAD 0 Coloca this na pilha de operadores | this 
DUP Copia o topo da pilha. Agora temos | this, this 

duas cópias de this na pilha de 

operadores. 


GETFIELD lastId | Recupera o valor de lastId a partir | this, 42 
do objeto apontado no topo da 
pilha (this) e armazena tal valor 
novamente na pilha. 


ICONST 1 Insere a constante inteira 1 na pilha. | this, 42, 1 
IADD Adiciona os dois valores inteiros | this, 43 

no topo da pilha de operadores e 

armazena o resultado de volta na 

pilha de operadores. 
DUP. X1 Duplica o valor 43 e o coloca antes | 43, this, 43 


de this. 


PUTFIELD value Armazena o valor do topo da pilha | 43 
de operadores, 43, no valor do 
campo do objeto atual, representado 
pelo valor consecutivo ao topo na 
pilha de operadores, this. 
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IRETURN retorna apenas o valor do topo da | <empty> 
pilha. 


Imagine o caso no qual a primeira thread finaliza as três primeiras instruções, chega até 
GETFIELD e o adiciona e, então, é interrompida. Uma segunda thread assume о controle е 
executa todo o método. incrementando last Id em 1; ela recebe 43 de volta. Então, a primeira 
thread continua de onde havia parado; 42 ainda está na pilha de operadores, pois esse era о 
valor de last Id quando ele executou a GETFIELD. Ele adiciona 1 para obter 43 novamente с 
armazena o resultado. O valor 43 é retornado à primeira thread também. O resultado é que aquele 
1 do incremento se perde, pois a primeira thread passou por cima da segunda depois desta ter 
interrompido aquela. Sincronizar o método getNexId() resolve esse problema. 


Conclusão 


Não é necessário saber muito sobre bytecode para entender como as threads podem passar uma 
por cima da outra. Se puder entender este exemplo, ele demonstra a possibilidade de múltiplas 
threads passando uma sobre a outra, o que já é conhecimento suficiente. 

Dito isso, o que esse simples exemplo mostra é a necessidade de entender o modelo de memória 
suficientemente para saber o que é e o que não é seguro. É comum pensarem erroneamente que 
o operador ++ (seja de pré ou pós-incremento) seja atômico, pois ele obviamente não é. Isso 
significa que você precisa saber: 


* Onde há valores/objetos compartilhados 
* Qual código pode causar questões de leitura/atualização concorrentes 
* Como evitar ocorrência de tais questões de concorrência 


Conheça sua biblioteca 
Framework Executor 


Como mostramos no ExecutorClientscheduler. java (р. 321), o framework Executor 
surgido no Java 5 permite uma execução sofisticada usando-se uma coleção de threads. Essa 
classe está no pacote java.util.concurrent. 

Se estiver criando threads, e não usando uma coleção delas, ou estiver usando uma criada manualmente, 
considere usar о Executor. Ele tomará seu código mais limpo, fácil de acompanha e menor. 

O framework Executor unirá threads, mudará automaticamente о tamanho e recriará threads se 
necessário. Ele também suporta futures, uma construção comum de programação concorrente. 
Este framework trabalha com classes que implementam a Runnable e também com classes que 
implementem a interface Callable. Esta se parece com uma Runnable, mas ela pode retornar um 
resultado, que é uma necessidade comum em soluções multithread. 

Um future é útil quando o código precisa executar múltiplas operações independentes e esperar 
que ambas finalizem: 


public String processRequest (String message) throws Exception ( 
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Callable<string> makeExternalCall = new Callable<String>() ( 
public String call() throws Exception ( 
String result = "*; 
// faz um pedido externo 
return result; 
) 
J; 
Future<String> result = executorService. 
submit (makeExternalCall); 
String partialResult = dosomeLocalProcessing(); 
return result.get() + partialResult; 


+ 


Neste exemplo, o método começa executando o objeto makeExternalCall. O método 
continua com outro processamento. A linha final chama result .get (), que o bloqueia até 
que o future finalize. 


Soluções sem bloqueio 


A Virtual Machine do Java 5 tira proveito do projeto dos processadores modernos, que suportam 
atualizações sem bloqueio e confiáveis. Considere. por exemplo, uma classe que use sincronização 
(e, portanto, bloqueio) para proporcionar uma atualização segura para threads de um valor: 


public class ObjectWithValue ( 
private int value; 
public void synchronized incrementValue() { ++value; ) 
public int getValue() ( return value; } 

} 


O Java 5 possui uma série de novas classes para situações como essa: AtomicBoolean, 
AtomicInteger € AtomicReference são três exemplos; há diversas outros. Podemos 
reescrever o código acima para usar uma abordagem sem bloqueios, como segue: 


public class ObjectWithvalue ( 
private AtomicInteger value - new AtomicInteger(0); 
public void incrementValue() ( 
value.incrementAndGet(); 
D 
public int getValue() ( 
return value.get(); 
H 
} 


Mesmo que esteja usando um objeto em vez de um tipo primitivo e enviando mensagens, como 
incrementAndGet() em vez de ++, o desempenho dessa classe quase sempre superará o da 
versão anterior. Em alguns casos, cla será só levemente mais rápida, mas casos em que ela fique 
mais lenta praticamente não existem. 

Como isso é possível? Processadores modernos têm uma operação tipicamente chamada de 
Comparar e Swap (CAS, sigla em inglês). Essa operação é análoga ao bloqueio otimista de 
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bancos de dados, enquanto a versão sincronizada é análoga ao bloqueio pessimista. 

A palavra reservada synchronized sempre requer um bloqueio, mesmo quando uma segunda 
thread não esteja tentando atualizar o mesmo valor. Mesmo que o desempenho de bloqueios 
intrínsecos tenha melhorado de versão para versão, eles ainda saem caro. 

A versão sem bloqueio assume que múltiplas threads não costumam modificar o mesmo valor 
frequentemente o bastante para criar um problema. Em vez disso, ela detecta de forma eficiente 
se tal situação ocorreu e tenta novamente até que a atualização ocorra com sucesso. 

Essa detecção quase sempre sai menos cara do que adquirir um bloqueio, mesmo em situações 
que vão de moderadas a de alta contenção. 

Como a Virtual Machine consegue isso? A operação CAS é atômica. Logicamente, ela se parece 
com o seguinte: 


int variableBeingSet; 
void simulateNonBlockingSet(int newValue) ( 
int currentValue; 
do ( 
currentValue - variableBeingSet 


) while(currentValue != compareAndSwap(currentValue, newValue)); 
у 


int synchronized compareAndSwap(int currentValue, int newValue) ( 
if(variableBeingSet currentValue) ( 
variableBeingSet - newValue; 
return currentValue; 


) 
return variableBeingSet; 


} 


Quando um método tenta atualizar uma variável compartilhada, a operação CAS verifica se a 
variável sendo configurada ainda possui o último valor conhecido. Caso possua, ela é, então. 
alterada. Caso contrário, ela não é configurada porque outra thread está usando-a. O método 
tentando alterá-la (usando a operação CAS) percebe que mudança não foi feita e tenta de novo. 


Classes não seguras para threads 


Há algumas classes que, por natureza, não são seguras para threads. Aqui estão alguns 
exemplos: 


* SimpleDateFormat 

* Conexões a bando de dados 
* Contêineres em java.util 
* Servlets 


Note que algumas classes de coleção possuem métodos individuais que são seguros para threads. 
Entretanto, qualquer operação que envolva chamar mais de um método não é segura. Por 
exemplo, se você não quiser substituir algo numa HashTabl e porque cle já está lá, você poderia 
escrever o seguinte: 
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if(!hashTable.containskey(somekey)) ( 
hashTable.put(someKey, new SomeValue()); 
} 


Cada método é seguro para threads. Contudo, outra thread poderia adicionar um valor entre a 
containsKey e as chamadas a put. 


* Bloqueie primeiro a HashTable e certifique-se de que todos os outros usuários dela façam o 
mesmo — bloqueio baseando-se no cliente: 


synchronized(map) ( 
if(!map.conainsKey(key)) 
map. put (key,value); 

} 


* Coloque a HashTable em seu próprio objeto e use uma API diferente — bloqueio bascando-se 
no servidor usando um ADAPTER: 


public class WrappedHashtable«K, V» { 
private Map<K, V» map = new Hashtable«K, V»(); 
public synchronized void putIfAbsent(K key, V value) { 
if (map.containsKey(key)) 
map.put(key, value); 


H 


* Use as coleções seguras para threads. 


ConcurrentHashMap<Integer, String» map = new 
ConcurrentHashMap<Integer, 

String>(); 

map.putIfAbsent(key, value); 


A coleção java.util.concurrent possui funções como a putlfAbsent() para acomodar tais 


operações. 


Dependências entre métodos podem danificar 
o código concorrente 
Abaixo está um exemplo simples de uma maneira de inserir dependências entre métodos: 


public class IntegerIterator implements Iterator<Integer> 
private Integer nextValue - 0; 


public synchronized boolean hasNext() { 
return nextValue « 100000; 
) 


public synchronized Integer next() ( 
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if (nextValue == 100000) 
throw new IteratorPastEndException(); 
return nextValue++; 


) 


public synchronized Integer getNextValue() ( 
return nextValue; 
} 
} 


A seguir está um código para usar este Integerlterator: 


IntegerIterator iterator = new IntegerIterator(); 
while(itera.or.hasNext()) { 

int nextValue - iterator.next(); 

// faz algo com nextValue 


Se uma thread executar este código, nào haverá problema. Mas o que acontece se duas threads 
tentarem compartilhar uma ünica instáncia de IngeterIterator considerando que cada uma 
processará o valor que receber, mas cada elemento da lista só é processado uma vez? Na maioria 
das vezes, nada de ruim ocorre: as threads compartilham a lista, processam os elementos que 
receberem do iterator e param quando este finaliza. Entretanto, há uma pequena chance de que, 
no final da iteração. as duas threads interajam entre si e façam com que uma vá além do iterator 
€ lance uma exceção. 

O problema é o seguinte: A Thread 1 faz a pergunta hasNext (), que retorna true. Então ela é 
bloqueada e a Thread 2 faz a mesma pergunta. que ainda retorna true. Então, a Thread 2 chama 
next (), que retorna um valor como esperado, mas com um efeito colateral de fazer hasNext () 
retornar false. A Thread 1 reinicia, pensando hasNext () ainda é true, e, então, chama next (). 
Mesmo que os métodos estejam sincronizados, o cliente usa dois. 

Esse é o problema real e um exemplo dos tipos que surgem no código concorrente. Neste caso 
em particular, este problema é consideravelmente sutil, pois a única vez em que ele ocorre é 
durante a iteração final do iterator. 

Se acontecer das threads darem erro na hora certa, então uma delas poderia ir além do final do 
iterator. Esse tipo de bug que ocorre bem depois de um sistema já está em produção, e fica dificil 
encontrá-lo. 
Você tem três opções: 


* Aceite a falha. 


* Resolva o problema alterando o cliente: bloqueio baseando-se no cliente. 


* Resolva o problema alterando o servidor, que adiciona alterações ao cliente: bloqueio 
baseando-se no servidor. 
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Aceite a falha 


Às vezes você pode configurar as coisas de tal forma que as falhas não causam mal algum. 
Por exemplo, o cliente acima captura uma exceção e a ignora. Francamente, isso é um pouco 
desleixado. É como reiniciar à meia-noite de modo a liberar a memória. 


Bloqueio baseando-se no cliente 


A fim de fazer о IntegerIterator funcionar corretamente com múltiplas threads, altere o 
cliente abaixo (e cada outro cliente), como segue: 


IntegerIterator iterator = new Integerlterator(); 
while (true) ( 
int nextValue; 
synchronized (iterator) ( 
if (!iterator.hasNext ()) 
break; 
nextValue = iterator.next(); 
} 


doSometingWith (nextvalue) ; 
} 


Cada cliente adiciona um bloqueio via a palavra reservada synchronized. Essa duplicação 
viola o Princípio do Não Se Repita (DRY, sigla em inglês), mas talvez seja necessário, caso o 
código use ferramentas de terceiros não-seguras para threads. 

Essa estratégia é arriscada, pois todos os programadores que usarem o servidor deverão se 
lembrar de bloqueá-lo antes de usá-lo e, quando terminar, desbloqueá-lo. Há muitos, muitíssimos 
anos atrás, trabalhei num sistema que usava num recurso compartilhado o bloqueio baseando-se 
no cliente. Usavam-se o recurso em centenas de lugares diferentes ao longo do código. Um pobre 
programador esqueceu de bloquear tal recurso em um desses lugares. 

O sistema era software de contabilidade executando um sistema com compartilhamento de tempo 
e diversos terminais para a Local 705 do sindicato dos caminhoneiros. O computador estava 
num nível elevado, em uma sala de ambiente controlado a 80 km ao norte da sede da Local 
705. Na sede, havia dezenas de funcionários digitando no terminal os dados dos relatórios de 
impostos sindicais. Os terminais estavam conectados ao computador através de linhas telefônicas 
exclusivas e modens semiduplex de 600 bps. (Isso foi há muito. muito tempo atrás). 

Cerca de uma vez por dia, um dos terminais “travava”. Não havia motivo para isso. O “travamento” 
não mostrava referência para nenhum terminal ou horário em particular. Era como se alguém 
jogasse dados para saber a hora e o terminal a bloquear. 

De vez em quando, mais de um terminal travava. Às vezes, passavam-se dias sem um 
travamento. 

À primeira vista, a única solução era uma reinicialização. Mas isso era difícil de coordenar. 
Tínhamos de ligar para a sede e pedir que em todos os terminais todos finalizassem о que 
estivessem fazendo. 

Então, poderíamos desligar e reiniciar. Se alguém estivesse fazendo algo importante que levasse 
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uma ou duas horas, o terminal bloqueado simplesmente teria de permanecer assim. 

Após poucas semanas de depuração, descobrimos que a causa era um contador de buffer circular 
que havia saído da sincronia com seu ponteiro. Esse buffer controlava a saída para o terminal. 
O valor do ponteiro indicava que o buffer estava vazio, mas o contador dizia que estava cheio. 
Como ele estava vazio, não havia nada a exibir; mas como também estava cheio, nào se podia 
adicionar nada ao buffer para que fosse exibido na tela. 

Portanto, sabíamos que os terminais estavam travando, mas não o porquê do buffer circular estar 
saindo de sincronia. Então, adicionamos um paliativo para contornar com o problema. Era possivel 
ler os interruptores do painel central no computador (isso foi há muito, muito, muito tempo). 
Criamos uma pequena função como armadilha para quando um detector desses interruptores fosse 
alterado e, então, buscávamos por um buffer circular que estivesse vazio e cheio. Se encontrasse 
um, o buffer seria configurado para vazio. Voilá! O(s) terminal(ais) travado(s) começa(ram) a 
funcionar novamente. 

Portanto. agora não tinhamos de reiniciar o sistema quando um terminal travasse. A Local 705 
simplesmente nos ligaria e diria que tinhamos um travamento, e, então, bastaria irmos até a sala 
do computador e mexer no interruptor. 

E claro que, às vezes, eles da Local 605 trabalhavam nos finais de semana, mas nós não. Então, 
adicionamos uma função ao programador que verificava todos os buffers circulares uma vez a 
cada minuto e zerava os que estavam vazios e cheios ao mesmo tempo. Com isso as telas abriam 
antes mesmo da Local 705 pegar o telefone. 

Levou mais algumas semanas de leitura minuciosa, página após página, do gigantesco código 
em linguagem assembly para descobrirmos o verdadeiro culpado. Haviamos calculado que a 
frequência dos bloqueios era consistente com um único caso desprotegido do buffer circular. 
Então, tudo o que tínhamos a fazer era encontrar aquele uso falho. Infelizmente, isso foi há muito 
tempo e não tinhamos as ferramentas de busca ou de referência cruzada ou qualquer outro tipo 
de ajuda automatizada. 

Simplesmente tivemos de ler os códigos. 

Aprendi uma lição importante naquele gélido inverno de Chicago, em 1971. O bloqueio baseando- 
se no cliente era realmente uma desgraça. 


Bloqueio baseando-se no servidor 


Pode-se remover a duplicação através das seguintes alterações ao Integerlterator: 


public class IntegerIteratorServerLocked ( 
private Integer nextValue = 0; 


public synchronized Integer getNextOrNull() { 
if (nextValue « 100000) 
return nextValue++; 
else 
return null; 
} 
} 
E o código do cliente também muda: 


while (true) ( 
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Integer nextValue = iterator.getNextOrNull(); 
null) 


it faz algo com nextValue 


} 
Neste caso, realmente alteramos a API de nossa classe para ser multithread". O cliente precisa 


efetuar uma verificação de null em vez de checar hasNext(). 
Em geral, deve-se dar preferência ao bloqueio baseando-se no servidor, pois: 


* Ele reduz códigos repetidos — o bloqueio baseando-se no cliente obriga cada cliente a bloquear 
o servidor adequadamente. Ao colocar o código de bloqueio no servidor, os clientes ficam 
livres para usar o objeto e não ter de criar códigos de bloqueio extras. 


* Permite melhor desempenho — você pode trocar um servidor seguro para threads por um não- 
seguro, no caso de uma implementação de thread única, evitando todos os trabalhos extras. 


* Reduz a possibilidade de erros — basta o programador esquecer de bloquear devidamente. 
* Força a uma única diretriz — um local, o servidor. em vez de muitos lugares, cada cliente. 


* Reduz o escopo das variáveis compartilhadas — o cliente nào as enxerga ou não sabe como 
estão bloqueadas. Tudo fica escondido no servidor. Quando ocorre um erro, diminui a 
quantidade dos locais nos quais onde procurar. 

* E se você não for o dono do código do servidor? 

* Use um ADAPTER para alterar a API e adicionar o bloqueio 


public class ThreadSafeIntegerIterator { 
private IntegerIterator iterator = new IntegerIterator(); 


public synchronized Integer getNextOrNull() ( 
if(iterator.hasNext()) 
return iterator.next(); 
return null; 


H 


* Ou, melhor ainda, use coleções seguras para threads com interfaces estendidas. 
Como aumentar a taxa de transferência de dados 


Assumamos que desejamos entrar na net e ler o conteúdo de uma série de páginas de uma lista de 
URLs. Conforme cada página é lida, analisaremos sua sintaxe para reunir algumas estatísticas. 
Após ter lido todas as páginas, imprimiremos um relatório resumido. 

A classe seguinte retorna o conteúdo de uma página dado um URL. 


public class PageReader ( 
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public String getPageFor(String url) ( 
HttpMethod method = new GetMethod(url); 
try { 
httpClient.executeMethod(method); 
String response = method.getResponseBodyAsString(); 
return response; 
} catch (Exception e) { 
handle(e); 
finally { 
method.releaseConnection(); 


H 


A próxima classe é o iterator que fornece o conteüdo das páginas baseando-se num iterator 
de URLS: 


public class Pagelterator ( 
private PageReader reader; 
private URLIterator urls; 


public Pagelterator(PageReader reader, URLIterator urls) { 
this.urls - urls; 
this.reader - reader; 

$ 


public synchronized String getNextPageOrNull() { 
if (urls.hasNext()) 
getPageFor(urls.next()); 
else 
return null; 
} 


public String getPageFor(String url) { 
return reader.getPageFor(url); 


$ 
Pode-se compartilhar uma instância de Pagelterator entre muitas threads, cada uma usando sua 
própria instância para ler e analisar a sintaxe das páginas que receber do iterator. 
Note que mantivemos o bloco synchronized bem pequeno. Ele contém apenas a seção crítica 
dentro do Pagelterator. E sempre melhor sincronizar o menos possível, e não o contrário. 


Cálculo da taxa de transferência de dados com uma 
única thread 


Agora, façamos alguns cálculos simples. Em relação aos parâmetros, assuma o seguinte: 


* Tempo de E/S recupera uma página (média): 1 segundo 
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* Tempo de processamento para analisar a sintaxe da página (média): .5 segundos 


* A E/S requer 0% do uso da CPU enquanto o processamento exige 100%. 


Única thread 


Analisando da sintaxe da página 


Recebendo a página | 4 4 pis rp b ALA LILA ALLA ALAS 


Para N páginas sendo processadas por uma única thread, o tempo total de execução é de 1,5 segundo 
+ N. A Figura A.| demonstra o processo com 13 páginas ou por volta de 19.5 segundos. 


Cálculo da taxa de transferéncia de dados com 
múltiplas threads 


Se for possível recuperar as páginas em qualquer ordem e processá-las independentemente, entào 
é possível usar múltiplas threads para aumentar a taxa de transferência de dados. O que acontece 
se usarmos múltiplas threads? Quantas páginas poderemos obter ao mesmo tempo? 

Como pode ver na Figura А.2, a solução multithread permite que o processo análise da sintaxe 
das páginas (uso do processador) se sobreponha com a leitura delas (E/S). Num mundo ideal, 
isso significa que o processador está sendo totalmente utilizado. Cada leitura de um segundo 
por página se sobrepõe com duas análises de sintaxe. Logo, podemos processar duas páginas 
por segundo, o que é três vezes maior que a taxa de transferência de dados da solução com 
uma única thread. 


Thread 1 


Aliada da sie de nido. = Dm) raf Drs PF oito 


LLLLLLLLELLLILLLELLIELLPELLELLLLLLLLLLLLS 


Thread 2 
Analisando da sintaxe da página 


Recebendo a página [L IL TL TL TL TLTUTLILTLTLTLTI 
LLLLLELELILILELELELLLLILLLILLLLLJ 

Thread 3 
Hin ce. атте TESTS 
LLLLLLLLLEI 


Figura A.2 - A solucào multithread 


Deadlock 


Imagine um aplicativo Web com dois conjuntos de recursos compartilhados de um tamanho finito. 


* Um conjunto de conexões a banco de dados para trabalho local no armazenamento do processo 
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* Um conjunto de conexões MQ para um repositório principal 
Assuma que haja duas operações neste aplicativo, criar e atualizar: 


* Criar — obtém conexão a um repositório principal ou um banco de dados. Comunica-se com o 
repositório principal de serviços e, então, armazena a tarefa no trabalho local no banco de dados 
do processo. 

* Atualizar — obtém conexão a um banco de dados e, então a um repositório principal. Lê a partir 
da tarefa no banco de dados do processo e. então. envia ao repositório principal. 


O que acontece quando o número de usuários é maior que o do conjunto de recursos? Considere 
que cada conjunto tenha um tamanho 10. 


* Dez usuários tentam usar o “criar”, então todas as dez conexões ao banco de dados ficam 
ocupadas, e cada thread é interrompida após obter tal conexão, porém antes de conseguir uma 
com o repositório principal. 

* Dez usuários tentam usar o “atualizar”, então todas as dez conexões ao repositório principal 
ficam ocupadas, e cada thread é interrompida após obter tal conexão, porém antes de conseguir 
uma com o banco de dados. 

* Agora, as dez threads “criar” devem esperar para conseguir uma conexão com o repositório 
principal, mas as dez threads “atualizar” devem esperar para conseguir uma conexão com o 
banco de dados. 


* Deadlock (bloqueio infinito). O sistema fica preso. 


Isso pode soar como uma situação improvável, mas quem deseja um sistema que congele 
infinitamente a cada semana? Quem deseja depurar um sistema com sintomas tão difíceis de 
produzir? Esse é o tipo de problema que ocorre no local, logo leva semanas para resolvê-lo. 
Uma “solução” típica é inserir instruções de depuração para descobrir o que está acontecendo. 
É claro que clas alteram bastante o código, de modo que depois o deadlock ocorrerá numa 
situação diferente e levará meses para acontecer de novo’. 

Para resolver de vez o problema de deadlock, precisamos entender sua causa. Há quatro condições 
para que ele ocorra: 


* Exclusão mútua 

* Bloqueio e espera 
* Sem preempção 

* Espera circular 


Exclusão mútua 


Isso ocorre quando múltiplas threads precisam usar os mesmos recursos e eles 


4. For example, someone adds some debugging output and the problem “disappears.” The debugging code “fixes” the problem so it remains in the system. 


Deadlock 333 


* Não possam ser usados por múltiplas threads ao mesmo tempo. 
* Possuem quantidade limitada. 


Um exemplo de tal recurso é uma conexáo a um banco de dados, um arquivo aberto para escrita, 
um bloqueio para registro ou um semáforo. 


Bloqueio e espera 


Uma vez que uma thread pega um recurso, ela nào o liberará até que tenha obtido todos os outros 
necessários para que ela complete sua tarefa. 


Sem preempcáo 


Uma thread nào pode tomar os recursos de outra. Uma vez que uma thread pega um recurso, a 
única forma de outra pegá-lo também é que a outra o libere. 


Espera circular 
Também chamado de “abraço mortal”. Imagine duas threads, T1 e T2. e dois recursos, R1 e R2. 


T1 possui R1, T2 possui R2. T1 também precisa de R2, e T2 de R1. 
Esse esquema se parece com a Figura A.3: 


Thread 1 
PA 
e е 
+ 


Y 
Recurso 2 Recurso 1 
‘ t 


7, 
V^ Thread 24 © 


Todas essas quatro condições devem existir para que ocorra um deadlock. Se apenas uma não 
estiver presente, o deadlock nào será possível. 


Como evitar a exclusão mútua 


Uma estratégia para evitar um deadlock é impedir exclusão mútua. Talvez seja capaz de fazer isso se você; 
* Usar recursos que permitam uso simultâneo, por exemplo, 0 AtomicInteger. 
* Aumentar a quantidade de recursos de modo que ele se iguale ou exceda o número de threads que 
competem por eles. 
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* Verificar se todos os seus recursos estão livres antes de usar um. 


Infelizmente, a maioria dos recursos possui número limitado e não permite uso simultâneo. E 
não é comum que segundo recurso dependa dos resultados obtidos ao usar o primeiro. Mas não 
desanime; ainda há três condições. 


Como evitar o bloqueio e espera 


Você também pode eliminar o deadlock se recusar-se a esperar. Verifique cada recurso antes de 
usá-lo, e libere todos os recursos e inicie novamente se tentar usar um que esteja ocupado. 
Essa abordagem adiciona diversos possíveis problemas: 


* Espera indefinida (Starvation)—uma thread fica impossibilitada de obter os recursos dos 
quais ela precisa (talvez seja uma combinação exclusiva de recursos os quais raramente 
ficam disponíveis). 

* Livelock—diversas threads podem ficar num entrave e todas obterem um recurso e, então. 
liberar um recurso, e assim indefinidamente. Isso ocorre especial e provavelmente com 
simples algoritmos de agendamento da CPU (pense em dispositivos embutidos ou threads 
simples criadas manualmente equilibrando os algoritmos). 


Ambos os problemas acima podem causar taxas de transferência de dados ruins. O primeiro 
resulta num uso baixo da CPU, enquanto o segundo causa um uso desnecessário e alto da CPU. 
Por mais ineficiente que essa estratégia pareça, ela é melhor do que nada. Isso porque há a 
vantagem de poder quase sempre implementá-la caso todas as outras falhem. 


Como evitar a preempção 


Outra estratégia para evitar um deadlock é permitir que as threads peguem os recursos de outras. 
Geralmente isso é feito através de um simples mecanismo de pedido. Quando uma thread descore 
que um recurso está sendo usado, ela pede ao seu utilizador que o libere. Se este também estiver 
esperando por algum outro recurso, ele libera todos e começa de novo. 

Essa técnica se parece com a anterior, mas com a vantagem de que se permite a uma thread 
esperar por um recurso. Isso reduz a quantidade de reinício de tarefas. Entretanto, tenha em 
mente que gerenciar todos aqueles pedidos pode ser traiçoeiro. 


Como evitar a espera circular 


Essa é o método mais comum para evitar um deadlock. Para a maioria dos sistemas é 
preciso nada mais do que uma simples convenção combinada por todos os colaboradores. 

No exemplo acima com a Thread 1 requisitando tanto o Recurso 1 como o Recurso 2, e a Thread 
2 esperando o Recurso 2 e, então o recurso 1, simplesmente força as Threads | e 2 a alocarem 
recursos na mesma ordem impossibilita a espera circular. 

De modo mais geral, se todas as threads puderem usar uma ordenação de recursos global e se 
todas os alocarem naquela ordem, então o deadlock se torna impossível. Como todas as outras 
estratégias, essa pode gerar problemas: 
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* A ordem de aquisição pode não corresponder com a de uso; embora um recurso obtido no 
início possa não ser utilizado até o final. Isso pode bloquear os recursos por mais tempo do 
que o necessário. 


* De vez em quando, você nào tem como ordenar a aquisição de recursos. Se a ID do segundo 
recurso vier de uma operação efetuada no primeiro, então a ordenação não é viável. 


Sendo assim, há tantas formas de evitar um deadlock. Algumas levam à espera infinita (starvation), 
enquanto outras aumentam em muito o uso da CPU e reduz a rapidez de resposta. 

Isolar a parte relacionada à thread de sua solução para permitir a sincronização e as experiências é 
uma maneira poderosa de obter o conhecimento necessário para escolher as melhores estratégias. 


Teste de código multithread 


Como criar um teste que mostre que o código seguinte está errado? 


01: public class ClassWithThreadingProblem ( 
02: int nextId; 


public int takeNextId() ( 
return nextId++; 


) 


A seguir está uma descrição de um teste que provará que o código está errado: 


* Lembre-se do valor atual de nextId. 

* Crie duas threads, cada uma chamando takeNextId() uma vez. 

* Verifique se nextld é maior duas vezes mais do que quando começamos. 

+ Execute até expor que nextId só é incrementado em uma unidade em vez de duas. 
A Listagem A.2 mostra esse teste: 


Listagem A-2 
ClassWithThreadingProblemTest .java 


01: package example; 


[ 


import s 


: org. junit Assert 


mport 


c class ClassWithThreadingProblemTest ( 


ubl 


Exception ( 
ngProblem 


= new ClassWithThreadingProblem() ; 
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Listagem A-2 (continuação) 
WithThreadingProblemTest . java 


let) ( 


takeNextId(); 


1=0;ic< 
startingId 
int expectedResul 


Linha 


Descricáo 


Cria uma única instância de ClasswithThreadingProblem. Note que 
devemos usar a palavra reservada final, pois a usamos embaixo de uma classe 
anônima interna. 


Crie uma classe anônima interna que use uma única instância de 
ClassWithThreadingProblem 


18 


Execute esse código quantas vezes for necessário para mostrar que o código 
falhou, mas não demasiadamente para que o teste “demore muito”. Este é 
um ato balanceado; não queremos esperar muito para expor uma falha. Pegar 
este número é difícil — embora mais adiante veremos que podemos reduzi-lo 
consideravelmente. 


19 


Lembre-se do valor inicial. Esse teste tenta provar que o código em na 
ClassWithThreadingProblem está errado. Se este teste passar, então ficou 
provado que o código é falho. Se não passar, o teste não foi capaz de provar 
que o código está errado. 


Esperamos que o valor final seja duas vezes mais do que o valor atual. 


PRE ЭИ SER NE E A 
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b2-23 Crie duas threads, ambas usando o objeto que criamos nas linhas 12-16. 
^ Isso nos dá as duas threads possíveis tentando usar nossa única instância de 
ClassWithThreadingProblem e que estão interferindo uma na outra. 
24-25 Torne executável nossas duas threads. 
26-27 Espere ambas as threads finalizarem antes de verificar os resultados. 
29 Registre o valor final atual. 
31-32 Nosso endingld difere do que esperávamos? Caso seja positivo, retorne e termine 
о teste — provamos que o código está errado. Caso contrário, tente novamente. 
35 Se chegarmos aqui, nosso teste foi incapaz de provar em tempo “razoável” 
que o código de produção estava errado; nosso código falhou. Ou o código 
não está quebrado ou não pudemos efetuar iterações suficientes para fazer a 
condição de erro acontecer. 


Este teste certamente configura as condições para um problema de atualização concorrente. 
Entretanto. ele ocorre tão raramente que na grande maioria das vezes este teste não o detectará. 
Na verdade, para realmente detectar o problema, precisamos configurar a quantidade de iterações 
para mais de um milhão. Mesmo assim, em dez execuções com um contador de loop a 1.000.000. 
o problema só acontecerá uma vez. Isso significa que provavelmente devemos colocar o contador 
da iteração bem acima de 100 milhões, de modo a obter falhas confiáveis. Quanto tempo estamos 
dispostos a esperar? 

Mesmo se direcionássemos o teste para obter falhas confiáveis em uma máquina, provavelmente 
teríamos de redirecioná-lo com valores diferentes para expor as falhas em outra máquina, sistema 
operacional ou versão da JVM. 

E esse é um problema simples. Se não pudermos mostrar facilmente com este problema que um 
código está errado, então como poderemos detectar problemas realmente mais complexos? 
Portanto, que abordagens podemos tomar para expor essa simples falha? E, o mais importante, 
como criar testes que demonstrem as falhas num código mais complexo? Como seremos capazes 
de descobrir se nosso código possui falhas se não sabemos onde procurar? 


Aqui estão algumas ideias: 


* Teste de Monte Carlo. Faça testes flexíveis, de modo que possam ser otimizados. Então, 
execute-os repetidas vezes — digamos, num servidor — aleatoriamente alterando os valores de 
otimização. Se os testes falharem, o código está errado. Certifique-se de começar a criação 
desses testes o quanto antes. Assim, um servidor de integração constante os inicia logo. A 
propósito, certifique-se de cuidadosamente registrar as condições sob as quais o teste falhou. 

* Execute o teste em cada uma das plataformas de implementação finais. Repetidamente. 
Constantemente. Quanto mais os testes executarem sem falha, mais provavelmente: 

— O código de produção está correto ou 
— Os testes não estão adequados para expor os problemas. 


* Rode os testes numa máquina com processos variados. Se você puder simular os processos 
parecidos a um ambiente de produção, faça. 
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Ainda assim, mesmo que você faça tudo isso, as chances de encontrar problemas com threads 
em seu código não são muito boas. Os problemas mais traiçoeiros são aqueles que possuem uma 
amostragem tão pequena que só ocorrem uma vez em um bilhão de chances. Eles são o terror de 
sistemas complexos. 


Ferramentas de suporte para testar códigos 
com threads 


A IBM criou uma ferramenta chamada ConTest*, Ela altera classes de modo a tornar menos 
provável que código não seguro para threads falhe. 

Não temos nenhum relacionamento direto com a IBM ou a equipe que desenvolveu o ConTest. 
Foi um colega nosso que o indicou a nós. Notamos uma grande melhoria em nossa capacidade 
para encontrar questões relacionadas a threads minutos após usar a ferramenta. 

A seguir está o resumo de como usar o ConTest: 


* Crie testes e código de produção, certifique-se de que há testes desenvolvidos especificamente 
para simular usuários múltiplos sob cargas variadas, como mencionado anteriormente. 


* Altere o teste e o código de produção com o ConTest. 
* Execute os testes. 


Quando alteramos o código com o ConTest, nossa taxa de êxito caiu bruscamente de uma 
falha em dez milhões de iterações para uma falha em trinta iterações. Os valores do loop para 
diversas execuções do teste após a alteração são: 13, 23. 0, 54, 16, 14, 6. 69, 107, 49, 2. Portanto, 
claramente as classes alteradas falhavam muito antes e com confiabilidade muito maior. 


Conclusão 


Este capítulo foi uma parada muito breve pelo território amplo e traiçoeiro da programação 
concorrente. Abordamos muito pouco aqui. Focamo-nos nas técnicas para ajudar a manter o 
código concorrente limpo. mas há muito mais a se aprender se quiser criar sistemas concorrentes. 
Recomendamos que comece pelo maravilhoso livro de Doug Lea chamado Concurrent 
Programming in Java: Design Principles and Patterns”. 

Neste capítulo falamos sobre atualização concorrente e as técnicas de sincronização limpa e 
bloqueios para evitá-la. Discutimos sobre como as threads podem aumentar a taxa de transferência 
de dados de um sistema baseado em E/S e mostramos técnicas limpas para alcançar tais melhorias. 
Falamos também sobre deadlock e as técnicas para evitá-lo de uma forma limpa. Por fim, discutimos 
sobre estratégias para expor os problemas concorrentes através da alteração de seu código. 
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Tutorial: Exemplos com códigos completos 


Cliente/servidor sem threads 


Listagem A-3 
Server.java 


package com.objectmentor.c rver .nonthreaded; 


import java.io.i0Exception; 
import .net.ServerSocket; 
mport java.net.Socket; 

port java.net.SocketException; 


import common. 


public class Server implements &unnai 
ServerSocket serverSocket; 
colatile boolean keepProcessin 


public Server(int port, int millisecondsTimeout) thr IGException i 
serverSocket = new ServerSccket (port); 


serversoc meout imillisecondaTimeout) ; 


public void ) 
stem. out. pr: 


("Server Startingin"i; 


while ikeepPro: 


try í 


sing) 


узсел. out .printf(*accep 
оске: socket = serverSock 


private void handie(Exception e 
if (1(e instanceof SocketExceptioni) { 
e.printstackTrace(]; 
} 


public void stopProcessing() | 
keep2recessing = false; 
closeignoringException (serverSocket! ; 
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Listagem A-3 (continuação) 


Server. java 


void process iSocket socket; ( 
if (socket null) 
return; 


tty { 
System.out .printf ( "Serve! 
String message = Messag: 
System.out.printf("Server: gor messag 
Thread.sleep(:000); 
Svstem.out .printf ('Server: sending reply: &sin', message); 
MessageUt ils. sendMessage (socket, "Processed: * + message}; 
System.out.printfi "Server: sentin'); 
closeIgnoringException (socket); 

} catch (Exception e) { 
e.printStackTrace(}; 


getting message\n"); 
Utils. getMessage (socket) ; 
gsi message); 


ate void closefgnoringExceptioniSocket socket] ( 


ult) 


socket .close|); 
catch (10Exception ignore) { 


8 


ion(ServerSocket serverso: 


private void closergnoringExcep: 
if iserverSocket !- null) 
try ( 
serverSocket.close(); 
) catch (IOException ignore) { 
} 


Listagem А-4 


ClientTest.java 


package com, objectmentor.clientserver .nonthreade 


a 


import java.io. IOExcepti 
import java.net .ServerSccket; 
import java.net .Socket; 

import java.net.SocketException; 


import common.MessageUti 


public class Server implements Runnable { 
erverSocket serverSocket; 
volatile boolean keepProcessing = true; 
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Listagem A-4 (continuação) 
ClientTest.java 
public Server(int port, int millisecondsTimeout) throws lOException { 
serverSocket = new ServerSo port); 
serverSocket .setSoTimeout (miliisecondsTimeout) ; 


public void runi) { 
System.out.print£ ("Server Starting\n"); 


while keepProcess:na) ( 
try { 

stem.out.printf ("accepting client in"); 
Socket socket = serverSocket.accept(); 
System.out.printfi*got clientin"); 
process (socket); 

) catch (Exception e! { 
handle(e); 


) 


private void handle(Exception e) { 
= (!(e instanceof SocketException!) { 
e.printStackTrace() ; 


public void stopProcessing() ( 
keepProcessing = false; 


(socket 
return; 


try ( 
System.out.print£(*Server: getting message\n") ; 
String message = MessageUtils.getMessage (socket); 
System.out .printf ("Serva message); 
Thread.sleepi1609); 
System.out.printf("Server: sending reply: ts\n", message); 
Messageltils.sendMessage (socket, "Processed: " + message}; 
System.out.printf("Server: sent\n"); 
closeIgnoringException (socket) ; 

| catch (Exception e) { 
e.printStackTrace(); 


private void closeTgnoringkxceprionisocket socket) { 
if (socket != null) 
try ( 
socket .close() ; 
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Listagem A-4 (continuação) 
ClientTest.java 


Socket serverSock 


private void clos 
if (Бегу 


t= null) 


serverso: 


i catch (ТОЕх 


Listagem A-5 
MessageUtils.java 


package common; 


.IOException; 
Inputstream; 

Object Input Stream; 
.ObjectOutputStream: 
Oute 


ssageUtils { 
c senduessage Socket socket, 5 


ng message) 


throws IOException i 
OutputStream stream = sock OutputStream | 
ream oos = new ObjectOutputStream(stream): 
оов .writeUTF (message) ; 
cos. flushi); 


public stati getMessage(Socket socket) throws IOException { 
InputStream stream = socket.getInputStream(); 
ObjectInputStream cis = new ObjectInputStream(stream): 


turn ois.readUTr (); 


Stri 
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Cliente/servidor usando threads 


Alterar o servidor para usar threads requer simplesmente uma mudança no processamento da 
mensagem (novas linhas foram realçadas para dar ênfase): 


void process(final Socket socket) ( 
if (socket null) 
return; 


Runnable clientHandler = new Runnable() ( 
public void run() { 
try ( 
System.out.printf("Servidor: recebendo 
mensagem\n"); 
String message = MessageUtils. 
getMessage(socket); 
System.out.printf("Servidor: mensagem 
recebida: %s\n", message); 
Thread.sleep(1000); 
System.out.printf(“Servidor: enviando 
resposta: %s\n", message); 
MessageUtils.sendMessage(socket, 
“Processado: " + message); 
System.out.printf("Servidor: enviado\n"); 
closeIgnoringException(socket); 
} catch (Exception e) ( 
e.printStackTrace(); 


Thread clientConnection - new Thread(clientHandler); 
clientConnection.start(); 


Apêndice B 


org.jfree.date.SerialDate 


Listing B-1 

SerialDate.Java 
2 * JComwon : a free genera! purpose 
5 * 10) Copyright 2000-2005, by Object Refinery Limited and Contributors. 
é 


oject Info: http://wew.jfree.org/jcommon/index.html 


This library is free software; you can redistribute it and/or modi 
under the terms of the GNU Lesser General Public License as published by 
the Free Software Foundation; either version 2.1 of the License, or 

fat your option) any later version. 


This library is distributed in the hope that it will be useful, but 
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
ог FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Pub 
License for 1 


You should have rece 
License along with t 
Foundation, Inc., 51 


ived a copy of the GNU Lesser General Public 
his library; if not, write to the Free Softwar 
ranklin Street, Fifth Floor, Boston, МА 021 


[Java is a trademark or registered trademark of Sun Microsystems 
the United States and other countri 


iC) Copyright 2001-2005, by Object Refine: 


Original Author: David Gilbert (for Object Refinery Limited); 


SerialDate.java,v 1.7 2005/11/03 0 7 mungady Exp $ 


Changes (from 11- 


t-2001) 
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38 
0 
а 


11-Oct-2001 : Re-organised the class and moved it to new package 
con. jrefinery date 106); 
05-Nov-2001 : Added a getDescription() method, and eliminated NotableDate 
class 106); 
12-Nov-2001 : IBD requires setDescript:on() method, now that NotableDate 
class is gone (DG); Changed getbreviousDayOfWeeki) , 
getFoliowingDayOfWeeki) and getNearestDayOfWeeki) te corre 
bugs (DG) 
+ Fixed bug in SpreadsheetDate class (00); 
: Moved the month constants into a separate inre 
(MonthConstants) (DG); 
Fixed bug in addMonths() method, thanks to N???levka Petr (DG); 


27-Aug-2002 


93-Oct-2002 : Fixed errors reported by Checkstyle (DG): 
Z * 13-Mar-2003 : Implemented Serializable (DG); 
29-May-2003 : Fixed bug in addMonths method (DG); 
04-Sep-2003 : implemented Comparable. Updated the isInRange javadocs (DG); 


05-Jan-2005 : Fixed bug in addvears 


) method (1096282) (DG); 


i 


package org. j£ree.date; 


import java, io.Serializable; 
import java.text.DareFormatSymbols; 
import java. text .SimplelateFormar; 
import java. util.Calendar; 

import java.util.GregorianCalendar; 


An abstract class that def: 


es our requirements for manipulating dat 
without tying down a particular implementation. 

<P> 
Requirement 1 
Requirement 2 
<P> 

Why not just use java.util.Date? We will, when it makes sense. 


* match at least what Excel does for dates; 
* java.util.Date can be *too* precise - it represents an instant in 


ass is inmutable; 


rate to l/1000th of a second (with the date itself depending on the 
me-z0ne]. Sometimes we just want to represent a particular day (e.g. 21 

January 2015) without concerning ourselves about the cine of day, or the 

time-zone. or anything else. That's what we've defined SerialDate for. 

<> 

You can call 

without wor 


tInstancel) to get a concrete subclass of SerialDate, 
ing about the exact implementation. 


* éxuthor David Gilbert 

public abstract class SerialDate implements Comparable, 
Serializable, 
MonthConscants ( 


#** For serialization. */ 


private static final long serialVersionUID = -29371604006742263 


^** Date format symbols, */ 
public static final DateFormatSymbols 
DATE FORMAT. SYMBOLS = new SimpleDateFormat |) .getDateFormarSymbols 


** The serial number for 1 January 190 
public static final int SERIAL LOWER BOUND 


"же The serial number for 31 December 9999. 
public static final int SERIAL UPPER BOUND 
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103 {** The lowest year value supported by this dare format. */ 
public static final int MINIMUM YEAR SUPPORTED - 1300; 


“e The highest year velue supported by this date format. * 
public static final int MAXIMUM YEAR SUPPORTED = 9999; 


** Useful constant for Monday. Equivalent te java.util.Calendar.MONDAY. * 
public static final int MONDAY = Calendar.MONDAY 


* Useful constant for Tuesday. Equivalent to java.util.Calendar.TUESDAY. 


public static final int TUESDAY = Calendar, TUESDAY; 


* Useful constant for Wednesday. Equivalent to 
* java. util.Calendar.WEDNESDAY 


public static final int WEDNESDAY = Calendar WEDNESDAY; 


* Useful constant for Thrusday. Equivalent to java util. 


public static final int THURSDAY = Calendar. THURSDAY: 


** Useful constant for Friday. Equivalent to java util.Calendar.FRIDAY. */ 
public static final int FRIDAY - Calendar.FRIDAY; 


* Useful constant for Saturday. Equivalent to java.util.Calendar.SATURDAT. 


public static Final int SATURDAY = Calendar. SATURDAY; 


va .ut1] Calendar . SUNDAY. */ 


** Useful constant 
public stetic final 


Sunday. Equivalent ti 
t SUNDAY = Calendar. SUNI 


The number of days in each month in non leap years. * 
tatic final int] LAST DAY OF MONTH = 
10, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]; 


/** The number of days in a (non-leap| year up to the end of each month. * 
static final int[! АССРЕСАТЕ DAYS TO END OP MONTE = 
i0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365}; 


/** The number of days in a year up to the end of the preceding month. * 
static final int[] AGGREGATE DAYS TC END OF PRECEDING MONTH 
(0, 0, 31, 53, 90, 120, 151, 181, 212, 243, 273, 304, 3 


/** The number of days in a leap year up to the end of each month. */ 
static final incl] LEAP YEAR AGGREGATE, DAYS TO, END OF. MONTH 
i0, 31, 60, 31, 152, 182, 213. 244, 274, 305, 325, 3 


* The nusber of days in a leap year up to the erd of the preceding month. 
static final int[] 
LEAP YEAR AGGREGATE DAYS TO END OF PRECEDING MONTE = 
(0. 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366]; 


** A useful constant for referring to the first week in a month. */ 
public static final int FIRST WEEK IN MONTH - 1; 
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/** A useful constant fcr referring to the second week in a month. *. 
public static final int SECOND WEEK IN MONTH = 


** à useful constant for referring to the third week in a month. * 
public static final int THIRD WEEK IN MONTH - 3; 


pub 


useful constant for referring to the fourth week in a monti 
static int FOURTH WEEK IN MONTE = 4: 


** A useful constan: for referring to the last week in a month. * 
public static final int LAST ИРЕК IN MONTH 


‘** Useful range constant. * 
public static final int INCLUDE NONE = 0; 


** Useful range constant. */ 
public static final int INCLUDE FIRST 


{** Useful range constant. */ 
public static final int INCLUDE SECOND = 2; 


/** Useful range constant. *7 
public static final int INCLUDE BOTH - 3; 


* Useful constant for specifying a day of the week relative to a fixed 


* date. 


public static final int PRECEDING 


* Useful constant for specifying a day of the week relative to a fixed 
* date. 
public static final nt NEAREST = 0; 


* Useful constant for specifying a day of the week relative to a fixed 
* date, 


public static final int FOLLOWING = 


/** à des 
private 


ption for the date. */ 
tring description; 


E 


* Default constructor. 


protected SerialDate() ( 
) 


* Returns «code»true«/code» if the supplied integer code represents а 
* valid day-of-the-week, and <code>false</code> ctherwise. 


* aparam code the code being checked for validity. 


* @return «code»true«/code» if the supplied integer code represents а 
£ valid day-of-the-week, and <code>false</code> otherwise. 


public static boclean isvalidWeekdayCode(final int code) ( 
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switchicode) { 

case SUNDAY: 
case MONDAY: 
case TUESDAY: 
case WEDNESDAY: 
case THURSDAY 
case FRIDAY: 
case SATURDAY: 

retura true; 
default: 

return faise: 


Converts the supplied string to a day of the week. 
üparam s a string representing the day of the week. 


return «code»-i«/code» if the string is noc convertable, the day of 
the week otherwise. 


public static int stringToWeekdayCode(String sj { 


final String|] shortWeekdayNames 
= DATE FORMAT. SYMBOLS. get ShortWeekdays () ; 
final String[] weekDayNamos = DATE FORMAT SYMBOLS .getWeekdays(); 


int result = - 
trimi) 


i < weekDayNames.lencth; i++) ( 
ihortWeekdayNames[i])) { 


П 
if (s.equals (меекдаумалев [1])} ( 
result = і; 
break; 
} ) 


return result: 


Returns a string representing the supplied day-of-the-week. 
<P> 
Need to find a better approach. 


@param weekday the day of the week. 


+ 


@return a string representing the supplied day-of-the-week. 


public static String weekdayCodeToStringifinal int weekday) { 


final String[] weekdays = DATE_FORMAT_SYMBOLS 
return weekdays [weekday] ; 


etWeekdays (! 
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89 
90 


* Returns an array of month names. 


* éreturn an array of month names. 
* 


public static String[) getMonthsii ( 


return getMonthe (false) ; 


} 


* Returns an array of month names. 
* Gparam shortened a flag indicating that shortened month names should 
Ы be rerurned, 


return an array of month names. 


public static String!) getMonthsifinal boolean shortened) { 


if (shortened) { 
return DATE FORMAT SYNBOLS. getShorrMonths () ; 


else { 


return DATE FORMAT SYMBOLS,getMonthst) ; 


Returns true if the supplied integer code represents a valid month. 


he code being checked for validity. 


Sreturn <code>true</code> if the supplied integer code represents a 


* aparan code 
* valid month. 


public static boolean isValidMonthCodeifinal int code) { 


ewitchicode) [ 
case JANUARY: 


return t 
wit: 
return false: 


jee 


* Returns the quarter for the specified month 
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“param cede the month code (1-12i. 


* Greturn the quarter that the month belongs to. 
* @throws java. lang.11legalArgument Except ion 


public stati 


int monthCodeTóQuarter|final int code) ( 


switchicode) { 
case JANUARY: 


case А 
case 
case JUNE: return 2; 
case JULY: 
case AUGUST 
case SEPTEMBER: return 3; 

case OCTOBER: 

case NOVEMBER: 

case DECEMBER: return 4 

default: throw new IilegalArgumencException! 
‘SerialDate.monthCodeToQuarter: invalid month code. 


Returns a string representing the supplied month. 
<P> 

The string x 
default locale. 


urned is the long form of the month name taken from the 


* &param month the month, 
* @return a string representing the supplied month. 


public static String monthCodeToStringífinal int month) { 


return montiCodeToStri! 


(доге, false); 


Returns a string representing the supplied month. 
<P> 

The string returned 1s t| 
from the default locale. 


long or short form of the month name taken 


@param month the month. 
üparam shortened 1f <codestruec/code> return the abbreviation of the 
month. 


Greturn а st 
throws java. 


g representing the supplied month. 
-lang.1llegalArgumentException 


public static String monthCodeToStringifinal int month, 
final boolean shorten 


check arguments. 
if (1isVelidMonthCode (month) ) ( 
throw new LllecaiàrgunentExceptioni 
*SerialDate.monthCcdeTostring: month outside valid range." 
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3 
ais 


415 


public static int erringToMonthCede(String s) ( 


b 
final String[] months; 


if (shortened) ( 

months = DATE FORMAT. SYMBOLS.getShortMonchs (}; 
) 
else i 

months = DATE FORMAT SYNBOLS.getMonths (i; 


return months[montk - 1]; 


Converts a string 
<P> 

This mecho will return ore of the constants JANUARY, FEBRUARY, ..., 
DECEMBER that corresponds to the string, the string 
recognised, this method returns -1. 


a month code. 


Gparam s the string to parse. 


éreturn «code»-le/code» if the string is not parseable, the month of the 
year otherwise. 


final String[] shortMonthNames = DATE FORMAT SYMBOLS.gerShortMonthsi): 
final Strinc[] monthNames = DATE FORMAT STMEOLS.getMonthe|): 


int result - -1; 


= = s.trin( 


é/ first try parsing the string as an integer (1-12)... 
try { 
result = Integer.parseInt (s); 


è 

catch iNumberFormatexception ei ( 
suppress 

1 


/ now search through the month names... 
if (iresult < 1) || (result > 12)) ( 
for iint 0; i < monthNames.lengrh; i++) ( 
if (s.equals(shortMonthNames[i]]) í 
result = i + l; 
break; 


+ 
if (s.equals(monthNames[i]!) ( 
result = i + 1; 
break 


return result; 
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Returns true if the supplied integer code represents a valid 
week-in-the-month, and false otherwise. 


Gparam code the code being checked for validity. 
return «code»true«'code» if the supplied integer code represents а 
valid week-in-the-month. 


public static boolean isValidNeokInMonthCodeifinal int code) ( 
switch (code) ( 
case FIRST WEEK IN MONTH: 
case SECOND WEEK IN MONTH: 
case THIRD WEEK IN MONTH 
case POURTH WEEK IN MONTH. 
case LAST WEEK IN MONTH: return t 
default: return false: 


* Determines whether or net the specified year is a leap year. 


Gparam yyyy the year (in the range 1900 to $399]. 


éreturn «code»truec/code» if the specified year is a leap year. 


public static boolean isLeapYear(final int yyy) { 


it (tyyyy #4) 
return fal 
} 


else if {(уууу % 4001 
return true; 


1 
else if (iyyyy % 100) == 0) ( 
return false; 


} 
else { 
return true; 


+ Returns the number of leap years from 1900 to the specified year 
* INCLUSIVE. 

+ <P> 

* Note that 1900 is not a leap year. 


éparam yyyy the year (in the range 1900 to 9999). 


@return the number of leap years from 1900 to the specified year. 


public static int leapYearCount (final int yyyy) { 


final int leap4 = (уууу - 1996) / 4; 
final ant 1еар100 = tyyyy - 1600) / 100; 
final int leapióD = (уууу - 1600) / 400; 
return leapi - leapl00 + leap400; 
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Returns the number of the last day of the month, raking into account 
leap years. 


* Gparam month the month. 
* Gparam yyyy the year (in the range 1900 tc 9999), 


Greturn the number of the last day of the monti 


public static int lastbayOfMonthifinal ant month; final int уууу) { 


final int result = LAST DAY OF MÓNTR|month|: 
if (month !- FEBRUARY) ( 

return result; 
} 


else if (isteapYeartyyyy)) { 
return result + 1; 


se { 
return result; 


* Creates а new date by adding the specified number of days to the base 
* date, 

* aparan days the number of days to add (сап be negativel. 

* éparam base the base date. 


* &return a new date. 


public static SerialDate addDays(final int days. final SerialDate base) { 


final int seriaiDayNunber = base-toSeriallj + дау 
return SerialDate.createlnetance(serialDayNumber) ; 


* Creates a new date by adding the specified number of months to the base 
* date. 
ep» 
If the base date is close to the end of the month, the day on the result 
may Бе adjusted slightly: 31 May + 1 month = 30 June. 


* Gparam months the number of months to add (сап be negative). 
* éparam base the base date. 


üreturn a new date. 


public static SerialDate addMonthsifinal int months. 
iinal SeriaiDate base) ( 


final int yy = (12 * base.getYYVY() + base.gerMonth() + months - 1) 


12; 
final int mm = {12 * Базе.де:ҮҮҮҮ(} + base.detMonth|) + months - 1) 
%12+1; 


final int dd = Mach min( 
base. getDay0fMonth(), Serialhate. lastDayôfMonthirm, yy! 
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E Jr 

500 return SerialDate.createInstanceidd, sm, уу); 

601 

$2 } 

603 

604 “ 

605 * Creates a new date by adding the specified number of years to the base 
606 * date. 

607 - 

&08 ~ @param years rhe number of years to add (can be negative). 

* Sparam base the 

610 * 

eu * @return А new date, 

612 Ы 

612 public static SerialDate addYearsifinal int years, final SerialDate base) ( 
D" 

$15 final int Баве? = base.getYYYY(); 


nal int baseM = base.gecMonth(); 
nal int baseD = base.getbeyOfMonth(); 


519 final int targetY - baseY + years; 

626 final int targetD = Math.min( 

$21 baseD, SerialDate.lastDayOfMonthíbaseM. targetY) 

622 E 

62: 

62 return Seri, Le.createInstance(targetD, baseM, targetY); 

625 

% } 

627 

oe ө 

626 + Returns the latest date that falls on the specified day-cf-the-week and 
$30 * is BEFORE the base date. 

$31 * 

632 * @param targetWeekday а code for the target day-of-the-week. 

622 * param base the base date, 

6M * 

835 * return the latest date that falls on the specified day-of-the-week and 
636 * is ВЕРОВЕ the base dare. 

637 + 

638 public static SerislDate getPreviousDayOfWeek (f: int targetWeekday, 
639 final SerialDate base; 


"Invalid day-of-the-week code.” 
n 


find the date... 
final int adjust; 
final int baseDOW = base.getDayOfWeek|); 
if (baseDOW > targetheekday) ( 
= Math.min(0, targetieekday - baseDOW); 


= 7 + Math.mex(0, targetWeekday - baseDOW); 


return SerislDate.addDays(adjust, base); 
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Returns the earliest date that falls on the specified day-of-the-week 
and is AFTER the base date, 


param targecWeekday a code for the target day-of-the-week. 
@param base the base date. 


@return the earliest date that falls on the specified day-of-the-week 
and is APTER the base date, 


public static SerialDate getFollowingDayOfWeek (final int targetWeekday, 
final SerialDate base) { 


check arguments 

if (!SerialDate isValidWeekdayCode (rargetweekday!) | 
throw new IllegalàrgunentException| 
"Invalid day-of-the-week собе." 


n 


find the date... 
final int adjust; 
final int baseDOW = base.getDayOfWeeki); 
if (baseDOW > zargetWeekday) ( 
adjust = 7 + Math.min(0, targetWeekday - baseDOW) ; 
) 
else ( 
adjust = Math.max(0, targetWeekday - baseDOW) ; 


} 


return SerialDate.addDsys (adjust. 


Returns the date falls on the specified day-of-the-week and is 


CLOSEST to the base date. 


Sparam base the base date. 


Greturn the date that falls on the specified day-of-the-week and is 


* 
* üparam targetDOW а code for the carget day-of-the-week. 
+ CLOSEST to the Баве date. 


alDate getNearestDeyOfWeek(final int targetDOW, 
final SerialDate à 


check arguments... 
if (!SerialDate.isValidWeekdayCode(targetDOW)) | 
throw new IllegalAzgumentException( 
"Invalid day-of-the-week code." 
» 


1 


if find the date... 
final int baseDOW = base.getDayOfWeek 
int adjust = -Math.abs(targetDOW - haseDOW) ; 
if (adjust t 

adjust = 7 - adjust; 


H 
if (adjust <= -4) ( 


adjust = 7 + adjust; 
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123 ) 
74 

725 

76 |] 

727 

728 d 


729 * Rolls the date forward tc the last day of the month. 
730 * 


turn SerislDate.addDays (adjust, base); 


üparam base the base date. 


* Greturn а new serial date. 


public Serialdate getEndOfCurrentMonthifinal SerialDate base) ( 
final int last = SerialDate, lastDayOfMonth( 
base.getMonth(), base.getYYYY!; 


urn SerialDate.createInstance (last, base.getMonth(), base.ge- 


@param count ar i 


ger code representing Lhe week-in-the-month. 


return a string corresponding to the week-in-the-month code 


* Need to find a becter approach. 


public static String weekInMonthToString(final int count) | 


switch (count) É 

case SerialDate. FIRST WEEK :N MONTH : return "Firet* 

case SerialDate.SECOND WEEK IN MONTE ; return "Second" 
case SeriaiDate.THIRD WEEK TH MONTH : return "Third"; 
case SerialDate. FOURTE WEEK IN MONTH : return "Fourth"; 
case SerialDate.LAST WEEK IN MONTH : return "Last"; 
deiault : 

return "SerialDate.weekInMonthTostring!): invalid code.*; 


Returns a 5 
<P> 
Need to find a better approach. 


ing representing the supplied ‘relative’. 


aparam relative a constant representing the ‘relative’ . 
@return a string representing the supplied ‘relative’. 
public static String relativeToString(final int relative) ( 


svite 


(relacive) { 
case SerialDate.PRECEDING : return "Preceding"; 
case SerialDete.NEAREST : return "Nearest"; 

case SeriaiDate. FOLLOWING : return "Following"; 
default : return "ERPOR : Relative To String" 
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786 * Factory method chat returns an instance of some concrete subclass of 
787 {Glink SerialDare). 
788 . 
788 * Фрағап day the day (1-31). 
790 * üparam month the month (1-12). 
791 * aparam yyyy the year (in the range 1900 to 9999). 
ES . 
793 * ereturn An instance of (Glink SerialDate}. 
294 m 
795 day, final int month. 
736 t yyyv) { 
297 return new SpreadsheerDateiday, month. yyyy); 
98 } 
799 
800 x 
801 * Factory method that returns an instance of some concrete subclass of 
#02 = 1@11лК SerislDare). 
803 * 
304 * Gparam serial che serial number for the day |! January 1900 = 21. 
205 ж 
806 * areturn a instance of SerialDate. 
307 bi 


public static SerialDate createInstancelfinal int serial) { 
return new SpreadsheetDate (serial); 


ictory method that returns an instance of a subclass of SerialDete. 
* aparam dete A Java date object. 


= @return а instance of SerialDate. 


public static Sei 


alDate createinstance(final java.util.Date date) { 


final GregorianCalendar calendar = new GregorianCalendar() ; 

calendar .setTime (dare); 

return new SpreadsheetDate (calendar .get (Calendar DATE), 
calendar „дес (Calendar .MONTH) + 1, 
calendar „де (Calendar. YEAR) ) ; 


Returns the serial number for the date, where 1 Janvary 1900 (this 
responds, almost, to the numbering system used in Microsoft Excel for 
* Windows and Lotus 1-2-3). 

. 


* éreturn the serial number for the date. 


public abstract int toSerial 


0: 


* Returns a java.util.Date. Since java.util.Date has more pre 


* Serialiate, we need to define a convention for the 'time of de 


* &return this as <code>java.util.Date</code>. 


public abstract java.util.Date toDate!l; 


ісп than 
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547 
848 


* Returns a description of the date. 


* éreturn a description of the date. 
public String getDescriptioni! { 
return this.description; 
) 


* Sets the description for the date. 


* param descripcion the new description for the date. 


public void setDescription(final String description) ( 


this.description - description; 


* Converts the date to г string. 
* @return a string representation of the date. 
public String toStringí) | 
return getbayOfMonth() + 


+ SerialDate.monthCodeToString igei 
+ getyYYY U; 


“ 
* Returns the year (assume a valid range of 1500 to 9999). 
+ @recurn the year. 


public abstract int getYYYY|); 


“ 
* Returns the month (January = 1, February = 


* @return the month of the year. 


public abstract int getMonth(); 


n 


* Returns the day of the month. 


* éreturn the day of the month. 


public abstract int getDayOfMonth|); 


* Returns the day of the week, 


* éreturn the day of the week. 


public abstract int getDayOfWeek(); 


* Returns the difference (in days) between this date and the specified 
* 'other' date. 

* <P> 

* The result is positive if this date is after the ‘other’ date апё 

* negative if it is before the 'other' date. 
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909 * 8param other the date being compared to. 

315 * 

91 * éreturn the difference between this and the other date. 
912 ү 


913 public abstract int compareiSerialDate other); 


s true if this SerialDate represents the same date as the 
* specified SerialDate. 


* @param other the date being compared to. 


&return <code>tri 


. </code> if this SerialDate represents the same dare as 
+ the spec 


fied SerialDate, 


public abstract boolean isOniSerialDate other); 

Returns true if this SerialDate represents an earlier date compared to 
the specified SerialDate. 

Gparam other The date being compared to. 


return <code>truec/code> if this SerialDate represents an earlier date 
+ compared to the specified SerialDate. 


public abstract boolean isBefore(SerialDate other); 


* Returns true if this SerialDate represents the same date as the 


êparan other the dare being compared to. 


Greturn «code»true«code» if this SerialDate represents the same date 
as the specified SerialDate. 


public abstract boolean isOnOrBefore(SerialDate other); 


E 
* Returns true if this SerialDate represents the same date as the 
specified SerialDate. 


* üperam other the date being compared to. 
* üreturn «code»true«/code» if this SerialDate represents the same date 


* as the specified SerialDate. 


ublic abstract boolean isAfter|SerialDate other); 


т 


@return «code»truec/code» if this SerialDate represents the same dare 
as the specified SerialDate. 


968 public abstract boolean isonOrAfter(SerialDate other); 


970 qe 
on * Returns <codestruec/code> 1f this (Blink SerialDate) is within the 
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Listing B-1 (continuacáo) 
SerialDate.Java 


specified range (INCLUSIVE). The date order cf dl and d2 is mot 
important. 


* @param dl а boundary date for the range 
* param d2 the other boundary date for 
+ 


range. 
@return А boolean. 


public abstract boolean isInRange(SerialDate dl, SerialDate d2i; 


if this (8 


Returns <code>truacio SerialDate) is within the 
specified range (caller specifies whether or not the end-points are 
included). The date order of dl and 42 is not important. 


Gparam 42 the other boundary date tor the range. 
Gparam include а code that controls whether or not the start and end 
dares are included in the ran 


* üparam dl a boundary date for the range. 


return A boolean. 


public abstract boolean isTnkange alDate 


int include); 


Returns the latest date that falls on the specified day-of-the-week and 
is BEFORE this date. 


param targetDOW a code for the target day-of-the-week. 


return the latest date that falls on the specified day-of-che-week and 
BEFORE this date. 


public SerialDate getPreviousDayOfWeekifinal int targetDOW) | 
return get PreviousDayOfWeek (targetDOM, this); 


+ Returns the earliest date that falls on the specified day-of-the-week 
and is APTER this date. 


Gparam targetDOW а code for the target -the-week. 


* @return the earliest date that falls on the specified day-of-the-week 


and is AFTER this dace. 


public SerialDate getFcllowingDayOfWesk(final int targetDOW) | 
return getFollowingDayO[Week(targetDON, this; 
} 
* 
+ Returns the nearest date that falis оп the specified day-of-the-week. 
* üparam targetDON a code for the target day-of-the-week. 
+ éreturn the nearest dare that falle on the specified day-of-the-week. 


public SerialDate getNearestDayOfWeekifinal int targetDOW) | 
return getNearestDayOfWeekitargetDOW, th. 
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SerialDateTest.java 


free general 


тагу for the Java(tm platform 


(€) Copyright 2000-2005, by Object Refinery Limited and Contributors. 


Project Info: http://www. jiree org; jcommon index.html 


ibute it and/or modify it 
License ag pub! by 
2.1 of the License, or 


This library is free software; you can redis! 
der the terms of the GNU Lesser General Pub! 
the Free Software Foundation; either vers: 


(at your option) any later version. 


This library is distributed in the hope thar it will be useful, bur 
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
or PITNESS FOR A PARTICULAR PURPOSE, See the GNU Lesser General Public 
License for more details. 


You should have received a copy of the GNU Lesser General Public 
License along with this library; if not, write to the Free Softwa 
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, МА 02 
USA. 


[Java is a trademark or registered trademark of Sun Microsystems, Inc. 
in the United States and other countrie: 


David Gilbert (for Object Refinery Linited); 


SerialDateTests.java,v 1.6 2005/11/16 15:58:40 taqua Exp $ 
Changes 


15-Nov-2001 : Version 1 (DG); 


-Jun-2002 : Removed unnecessary import (DG); 
24-Oct-2002 : Fixed errors reported by Checkstyle (DG); 
13-Mar-2003 : Added serialization test (DG); 


05-Jan-2005 : Added test for bug report 1096232 (DG): 


package org. jfree.dare 


java, io. ByteArrayInputStream; 
java. io. BytearrayOutpurstream; 
Java. io.0bjeccInput: 

java. io. Object InputStream: 

iva. io.ObjectOutput; 
a.io.ObjectOutputStream; 


+ junit.framework.Test 
junit.framework.TestCase; 
junit. framework. TestSuite; 


50 import org. jfree.date.MonthConstants; 
51 import org. jfree.date.SerialDate; 
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Listagem B-2 (continuação) 


SerialDateTest.java 


63 /** 
54 * Some JUnit tests for the {@11пК SerialDate] class. 
65 + 

65 public class SerialDateTests extends TestCase { 

67 

60 үе Date representing November 9, */ 

б private SerialDate nov9Y2001; 


* Creates a new test case. 


super (nane) ; 


* Returns a test suite for the JUnit test runner. 


* &return The test sui 
public static Test suitei) { 
return new TestauiteiSerialDateTests.class); 


ë, 


1 
e 


* Problem ser up. 
protected void setUpi) [ 
this.nov9¥2001 = 


lalDate.createInstance(9, MonthConstants.NOVEMBER, 2001]; 


+ 9 Nov 2001 plus two months should be 9 Jen 2002. 

~ 

public void testAddMonthsToINov2001() ( 

final Ser:alDate jan9¥2002 = SerialDate.addMonths|2, this 
final SerialDate answer = SerialDate.createlrstance|9, 1, 2002); 
assertEquals (answer, jan9¥2002); 


* à test case for a reported bug, now fixed. 
public void testAddMont! 
final SerialDate dl 


'056ct2003 (1 { 
SerialDate.createInstance(5, MonthConstants.OCTOBER, 2003); 


final SerialDate dż = SerialDate.addMonths (2, dll; 
assertEquals|d2, SerialDate.createInstance(5, MonthConstants. DECEMBER, 2003)); 

П 

* А test case for a reported bug, now fixed. 

public void testaddMonthsToiJan29031} ( 
final SerialDate SerialDate.createInstance(1, MonthConstants.CANUARY, 2003i; 
final SerialDate dz rialDate.addMonths(0, dl); 

_ assertEquals (42, dli; 


* Monday preceding Friday 3 November 2001 shouid be 5 November. 
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SerialDateTest.java 


publie void testMondayPrecedingFriday9Nov2001i) { 
SerialDate mondayBefore = SerialDate.getPreviousDayOfWeek( 
SerialDate.MONDAY, this.nov9Y2001 
IH 
assertEqualsi5, mondayBefore.getDayOfMonthi)i; 


g Friday 9 November 2001 should be 12 November. 
public void testMondayFollowingFriday9Nov2001(] { 
SerialDate mondayAfter = gerialDate.gerFollowingDayOfWeek! 
SeriaiDate.MONDAY, this.nov9Y2001 


n 
assertEquals!12, mondayAfter.getDayOfMonthi)]; 
“+ Monday nearest Friday 9 November 2001 should be 12 November. 


void LestMondayNearestFriday9Nov200L() { 
SerialDate mondayNearest = SerialDate.getNearestDayOfWeek( 
SerialDace.MONDAY, this.nov9Y2001 


assertEquals|12, mondayNearest.getDayOfMonth!]) ; 


e 
* The Monday nearest to 22nd January 1970 fi 


pubi 


с void testMordayNearestz2Jan1370] { 

erialDate jan22Y1970 = SerialDate.createinstance(22, MonthConstents.JANUARY, 1970); 
SerialDate mondayNearest-SerialDate.cetNearestDayOfWeek(SerialDate.MONDAY, jan22Y1970); 
assertEquals (19, mondayNearest .getDayOfMonth () ) 


П 


* Problem chat the conversion of days to strings returns the right result. Actually, rhis 
* result depends on the Locale so this test needs to be modified. 


public void testWeekdayCodeToString() ( 


g (SerialDate. SATURDAY) ; 


* Test the conversion of a string to a weekday. Note that this test will fail if the 
* default locale doesn't use English weekday names...devise a better test! 


public void testStríngToWeekday(] ( 


int weekday = SerialDate.stringlolleekdayCcde ( Wednesday") ; 
assertEquals (SerialDate.WEDNESDAY, weekday); 


weekday = SerialDate.stringToWeekdayCode(* Wednesday *); 
assertEquais(SerialDate.WEDNESDAY, weekday]; 
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SerialDateTest.java 


185 weekday = Serial! 
assertEquals (Ser: 


ite. stringToWeekdayCode ("Wed"); 
alDate.WEDNESDAY, weekday 


* Test the conversion of a string to a month. Note that this test will fail if the 
+ default locale doesn't use English month names...devise a better test! 
~ 


public void testStringToMonthCodei] { 


int m = SerialDate.stringToMonthCode i" 
asserrEquals(MonthConstants.JANUARY, п) 


rialDate.stringToMcnthCode(* January "|; 
assertEquals (MonthConstants JANUARY, m); 


m = SerialDate.stringToMonthCode(*Jan* 
assertEquals (MonthConstants JANUARY, m); 


= Tests the conversion of a month code to a string. 


publi 


void testMonthCodeToStringCode!) ( 


final String test = serialDate.monthCodeToString (MonthConstants . DECEMBER) ; 
assertEquals(*December*, test); 


* 1900 is not a leap year. 


public void tes 
assertTrue 


'sNotLeapYear1900() ( 
lerialDate.isLeapYear(19001] ; 


000 is a leap year. 


ic void testIsLeaprear2000() 1 
assertTrue LeapYear (2000) 1; 


Bm itt 

232 * The number of leap years from 1900 up-to-and-including 1899 is 0. 
233 " 

234 public void testLeapYearCountl899() | 

235 assertEquals (SerialDate. leapfearCount (1899), 0); 

26 } 


+ The number of leap years from 1900 up-te-and-including 1303 is 0. 
public void testLeapy 
assertEquals (Seri 


Count 1903 () ( 
iDate. leapYearCount (1903), 0); 


) 


* The number of leap years from 1900 up-to-and-including 1904 is 1. 
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SerialDateTest.java 


248 


YearCount1904() ( 
ialpate, leapYearCount (1904), 1); 


“ 


* The number of leap years from 1900 up-tc-and-including 1999 is 24 
“ 
public void testLeapyearCount1999() £ 
assertEquals Ibate, leapYearCount (1999), 24); 


* The nui 
public void restteapYearCount2000!) ( 
assertEquals (SerialDare, leapYearCount (2000), 25); 


of leap years from 1900 up-to-and-including 2000 ia 25. 


* Serialize an instance, restore it. and check for equality. 


public void testSerialization!) | 


SerialDate dl 
SerialDate 42 = 


.alDate.c: 
null; 


eateInstancei15, 4, 2000); 


чу! 
ByteArrayOutputStream buffer = new ByteArrayOutputstreami); 
ObjectOutput out = new ObjectOutoutStream(buffer) ; 
out .writedbject (di); 
out .close! 


Objectinput in = new Objectinputstream( 

new ByteArray InputStream (butfer.toByteArray(}}); 
(SerialDate) in.readObject (); 
n.closei); 


} 


catch (Exception е) { 
System.out.printinte.toString(i); 


i 
assertEquals(dl, 22); 


* A test for bug report 1096282 (now fixed). 
public void test1096282() ( 
SerialDate d alDate.createInstance(29, 2, 2004); 
d = SerialDate.addvears(1, d); 
SerialDate expected = Seriallate.createInstance(28, 2, 2005); 
assert True(d. isOn (expected! ) ; 


} 


sas 


* Miscellaneous tests for the addMonths() method. 
public void testAdàMonths | { 
SerialDate dl = SerialDate,createInstance(31, 5, 2004); 
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Listagem B-2 (continuação) 
SerialDateTest java 


SerialDete d? = SerialDate addMonthsil, dl); 
assertEquals(30, d?.cetDayOfMontk()); 
assertEquals(6, d2.gerMonth()]; 
assertEquals(2004, d2.getYYYYl)) ; 


SerialDate 83 = serialbate.addMonthsi2, dl); 
asserrEqualst51, d3.getDayOfMonth!) 


assertEquals(2004, d3.getyYYYU); 


alDate di = Ser:alDate.addMont! 
assertEquals(30, d4.gecDayOtMonth()) ; 
assertEqualz(7, d4.getMonth[)) ; 
assertEqualsi2004, d4.gecYYYY()) ; 


SerialDate,addMonths (1, d1)]; 
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9 


3 


e Java(tm) platform 


(С) Copyright 2000-20 


by Object Refinery Limited and Contributors. 


ject Info: he 


p:/ /www.jfree,org/jcommon/ index.html 


‘ee software; you car redistribute it and/or modify it 
under the ti: of the GNU ier General Pub! License as published by 
the Free Software Foundation; either version 2.1 of the License. or 

fat your opti later version. 


This library is distributed in the hope thar it will be useful, but 
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 
License for more details. 


You should have received a copy of the GNU Lesser General Publi 

License along with this library; if not, write to the Free Software 
Foundation, Inc., in Street, Fifth Floor, Boston, MA 02110-1301. 
E 


[Java is a trademark or registered trademark of Sun Microsystems, Inc. 
in the United States and other countries.] 


MonthConstants. java 


(c) Copyright 2002, 


003. by Object Refinery Limited. 


Original Author: David Gilbert (for Object Refinery Limited); 
Contributoris): -; 


$id: MonthConstants.java,v 1.4 2005/11/16 15:58:40 taqua Exp $ 
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MonthConstants. java 


dg + 
40 * 
ar 
2 

43 package org.jfree.date; 


45 je 
46 * useful constants for months 
4) * constants defined by java.util. 
ДЕ + <P> 

* Used by the SerialDate and RegularTimePeriod classes. 


* @author David Gilbert 


public interface MenthConstants | 


29-Мау-2002 ; Version 1 code moved from SerialDate class! (DG): 


Nore that these are NOT equivalent to 
alendar iwhere JANUARY=0 and DECEMBER: 


Listagem B-4 (continuação) 
BobsSerialDateTest. java 


1 package org.jfree. 


Junit- framework, TestC: 
ого. jtree.date.*: 


import java.unil.*; 
c class BobsSerialDateTest extends TestCase { 


public void tescIsValidieekdayCode() throws Exception ( 
for (int day = 1; day <= 7; day++) 
assert True (1s vali dWeekdayCode (day!) ; 
asserrFalse(isValidieekday 
assertFalse (isval idWeekdayCode (8)); 


public void testStringToWeekdayCode() throws Exception { 


assertEquals(-1, stringToWeekdayCode (*Hello*ll; 
assertEquals (MONDAY, stringToWeekdayCode ("Monday") ) + 
2 assertEquals(MONDAY, stringToWeekdayCode ("Mor 
//todo assertEquals (MONDAY, str ingToWeekdayCode ("monday") ) ; 
assertEquals (MONDAY, stri ngToMeekdayCode ("MONDAY") ) ; 
assertEgualsiMONDRY, stringToNeekdayCode! *non*]) ; 


assertEquals (TUESDAY, st: 
assertEquals (TUESDAY, 


ingToWeekdey Code ("Tuesday") i; 
.ngToWeekdey Code |*Tue* ; 
assertEquals (TUESDAY, stringToWeekdayCode | *їлгәвда 
assert Equals (TUESDAY, stringToWeekdayCode ( *TUESDA’ 
assertEquals (TUESDAY, stringToWeekdayCode 
assertEquals (TUESDAY, stringToWeekdayCcde i" 


ues") ) 


assertEquals (WEDNESDAY, stringToWeekdayCode | "we 
assertEquals (WEDNESDAY, stringToWeekdayCode i 


ay"); 
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Listagem B-4 (continuação) 
BobsSerialDateTest . java 


ASSeTTHquaLS|WSUNESUAY, StringYoweekaayUoae (“Wednesday”) | ; 
assertêquals WEDNESDAY, stringToWeekdayCode(*Wed")); 
assert Equals (WEDNESDAY , str ingToWeekdayCode | "wednesday" || ; 
assertEquals (WEDNESDAY, st. r1 ngToWeek3ayCode і "WEDNESDAY" ) ) ; 
assertEquals (WEDNESDAY, stringToWeekdayCode | "wed" | ; 


assertSquais'TRURSDAY. stringToWeekdayCode i *Thursday") | ; 

assertEquals|TEURSDAY, stringToWeekdayCode(*Thu")}; 
assertEquais (THURSDAY, st ringToWeekdayCode ("thursday"); 
assertEquals (THURSDAY, st riioToHeekdayCode ("THURSDAY") ) ; 
assertEquals(THURSDEY, etringToiWeekdayCode ("thu") 
assertEquals (THURSDAY. stringToWeekdayCode ("thurs") ); 


assertEquals (FRIDAY, stringToWeekdayCodei"Friday") |; 
48 assertEquals!FRIDAY, stringToWeekdayCode (* i 
49 fy assertEquals (FRIDAY, stringToWeekdayCode ( 
50 // assertEquais(PRIDAY, stringToWeekdayCode | "FRIDAY" i 
514) — assertEquals(FRIDAY, 


5 assertEquais (SATIRDA) i 

54 —— assertEquals(SATURDAY, stringToWeekdayCode!*Sat"} i 

55 2) assertEquals (SATURDAY, stri ngToWeekdayCode ("saturday") : 
56 2/ assertEquals (SATURDAY, stringToWeekdayCode i" SATURDAY" ) ; 
51. assertEquals (SATURDAY, stringToWeekdayCode(*sat"}) ; 

58 

59 assertEquals (SUNDAY, stringToNeekdayCoce( *Sunday*) |; 

60 assertEquals (SUNDAY, stringToWeekdayCode(*Sun*) ); 

& / dai E ERAT, eloa ‘sunday"!): 

63 it 

& } 

65 


public void testWeekdayCodeToString!) throws Exception { 
assertEquals |"Sunday*, weekdayCadeToString (SUNDAY! ); 
asserrEquals "Monday", weekdayCodeToString (MONDAY) ) ; 
assercEquals| *Tuesday*, weekdayCodeToString (TUESDAY) ); 
assertkquals|"Wednesday*, weekdayCodeTost (WEDNESDAY) ); 
assertEquals "Thursday", wcekdayCodeToString (THURSDAY) ) 1 
assertEquals (*Friday*, weekdayCodeToString (FRIDAY) ) ; 
assertEquals ("Saturday*, weekdayCodeToString (SATURDAY) |; 


lic void testisValidMonthCode() throws Exception | 
for lint i = 1 

assert True (Ì 
assertFalseiisVal 
rtFalse(is! 


83 public void testMonthToquarter!} throws Exception ( 
34 — assertEquals!l, monchCodeToQuarter (JANUARY)  ; 

85 — assertEquals(l, monthCodeToQuarter (FEBRUARY) ); 
86 — assertEquals(l, nonthCodeToquarter (MARCH) ) 


7 mat jeToQuarter (APRIL!) 
38  assertEquals2, monthCodeToQuarter (MAY) | 
82 assertEquals(2, monchCodeToQuarter (JUNE) 


90 assertEquals(3, monthCodeToQuarter JULY) |; 
31 — assertEquals|3, monthCodeToQuarter (AUGUST) ) ; 
92 assertEquals(3, monthCodeToQuarter | SEPTEMBER] | ; 
9з assertEquals(4, monthCodeToQuarter (OCTOBER) ! ; 
94 assertEquais(d monthCodeToQuarter NOVEMBER! ) + 
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m 


145 
146 
из 
148 
145 
150 
151 
152 


assertequais|4, montncoceróJuarter INUVEMBEXO 1; 
assertEquals |4, menthCodeToQuarter (DECEMBER) | ; 


try í 

monthCodeToQuarter (-1); 

fail('Invalid Month Code should throw exception"); 
} catch (Tl legaiargumentException e) ( 


1 
} 


public void testMonthtodeToString(! throws Exception { 
asserrEquals(*January*, monthCodeToString (JANUARY) |; 
assertEquals( "February", monthCodeToString FEBRUARY! |; 
assertEquals(*March*, monthCodeToString (MARCH) ) ; 
assertEquals(*April*, monthCodeToString (APRIL) j; 
assertEquals ("Мау", monthCodeToString (MAY) ) ; 
assertEquals("June", monthCodeTostring (JUNE) | 
assertEquals (*July*, monthCodeToString (JULY) ) ; 
assertEquals í"August*, monthCodeToString (AUGUST) |; 
assertEquals(*Septesber*, monthCodeTostring (SEPTEMBER) ) ; 
assertEqualsi*October*, monthCodeToString (OCTOBER) ) ; 
assertEquals("lovenber*, monthCadeTostring (NOVEMBER) | ; 
assertEquals(*Decenber*, monchCodeToString (DECEMBER) |; 


assertEquals 
assertêquals 


monthCodeToScring (JANUARY, truel); 
monthCodeToSt ring (FEBRUARY, truel); 
assertEquals(*Mar*, monthcodeToString (MARCH. true) |; 
assertEquals(*Apr*, monthCodeToString (APRIL, crue)]; 
assertEquals(*May*, monthCodeToString (MAY, true): 
assertEquals (* monthCodeToString (JUNE, true) ); 
assertEquals(*Jul", monthCodeToString (JULY, true) ); 
assertEquals moathCedeToString (AUGUST, true)); 
assertEquals monthCodeToString (SEPTEMBER, truel]; 
assertEqualsi"Oct'. monthCodeToString (OCTOBER, true)); 


assertEquals (*Nov", monthCodeToString (NOVEMBER, true)); 
assertEquals(*Dec*, monthCodeToString (DECEMBER, true!) ; 


uy ( 
monthCodefoStringl-1i; 
faili*Invalid month code should throw exception"); 


) catch (IllegalArgumentéxception e| ( 


public void testStringToMonthcode() throws Exception | 
assertEquals (JANUARY, stringToMonthCode (*1*) 1; 
assertEquals (FEBRUARY. stringToMontiCode (*2º) ) ; 
assertEquals (МАРСЕ, st ringToNont hCode (* 
assert Equals (APRIL, et ringToMont hCode (* 
assertEquals (MAY, stringToMonthCode 
assertEquals (JUNE, stringToMont hCode (*€ 
assertEquals (JULY, stringToMonthCode ( *7 
assertEquals (AUGUST, stringToMonthCode( 
assertEquals (SEPTEMBER, st ringToMonthCode | *9* ) 
assertEquals (OCTOBER, scringToMont hCode ( *10*) 
assertEquals (NOVEMBER, stringloMonthCode|*11*]): 
assert Equal s (DECEMBER, stringToMonthCode ("12") ) ; 


153 //todo _ assertEquals{-1, stringToMonthCode(*0*)); 


154 47 


assertBquale(-L, stringToMonchCode(*13*) i; 
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assertEquals(-1, scringToMonthCode ("Hello") 1; 


for (int m= 1; в < med) | 
assertEqualsim, stringToMonthCode(monthCedeToString(m, 
assertEqualsim, stringToMonthCode(monthCodeToString (m, 


assert Equals (1, stringToMenthCode (*] 
assertEquals (2, stringToMonthCode( 
assertEquals (3, stringToMonthCcde ("паг") 
assertEquals(4. stringToMonchCode (*apr*) 
assertEquals (5 
assertEquals (6,stringToMonthCode (*jun*] ); 
assercEquals (7, str ingToMonthCode (*ju1*] ) ; 
assertEquals (8, stringToMonthCode ("aug") ); 
assertEquals (9, stringToMonthCode ("вер"); 
онн st Ein nen 


assertEquals (5, stringToMonchCode ("MAR") ) 
assertEquals (4, stringToMonthCode ("APR") ) 
assert Equals (5, stringToMonthCode | *MAY") } 
assert Equals (6, stringToMont hCode (* JUN*] ) 
assertEquals (7.stringToMonthCode ( *JUL* ) | 
assertEquals (8, strzngToMonthCode ("AUG") ) + 
assertEquals (9, strinoToMonthCode ("S 
assertEquals (10, stringToMonthCode (* 
assertEquals(11,stringTeMonthCode ("NOV*1  ; 
assertEquals (12, stringToMonthCode ("DEC") ; 


assertEquals (1, stringToMonthcode "january")); 
assert Equals (2, stringToMont hCode ("february") |; 


assertEquals (3, sLringToMonthCode ("arch*]  ; 
assertEquals 4, scringToMonthCode (*april") i; 
assertEquals (5, stringToMonthCode (* 
assertEquals (é, stringToMonthCode ("june 
assertEquals 
assertEquals! 
asserrEquai 
assertEquals (10, stringToMonthCode | "october" 
assercEquals (11, st ringToMont hCode (*novenber* 
assertquals i12, stringToMonthCode ("decenber*)  ; 


assert Equals (1, stringToMonthcode JANUARY" 1; 
assertEquals (2, stringToMont hCode (* FEBRUARY"); 
assertEquals 3, stringToXont hCode ("NAR") ) ; 
assertEquale(4,stringToMonthCode "APRIL" ]) 
assertEquals (5, striagToNont hCode (“MAI 
assertEquals (6, stringToMont! 
assercquals(7, si 
assertEquals i8,stringToMonthCode 
assert Equals (9, stringToMonthCode  * SEPTEMBER") 
assertequals (10, stringToMonthCode ("OCTOBER") ) ; 
assertEquals (11, stringToNonthCode ("NOVEMBER") ) ; 
assertEquals (12, stringToMonthCode | "DECEMBER" |) ; 


false)!); 
truej)); 
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i 


) 


LidWeekinMonthCode() throws E) 


public void te: 


for (int w= 


assert True (isval idNeekinMonthCode (w) ) + 


р 
assertfalse(1sVaiidWeekinMonthCode(5)) ; 


assertFalseitsLeapYear (1905) | 
apyear (1901) | 
assertFalse|isheapYear (1902) j; 
assertFalseiisLeapYear!1903)] ; 
assertTrue (isLeapYear (1904) ) ; 
assert True(isLeapYear (1908) ; 
assertFalse|LsLeapfear [1955] ) ; 
assert True ( isLeapYear (1964]) ; 
assert True(isLeapYear (1380)  ; 
assert True (isLeapYear (2600) ); 
assertFalse(isleapyear 20011); 
rtFalselisLeapfear (2100) ); 


asserrkquals(0, leapYearCount (19001); 
aesertEquals(0, leapYearCount 11001); 
asserrêquals(0, LeapyearCount (19021): 
assertEquals (0, leapYearCount (1903)) ; 
assertEquals(1, leapearCount(1904]); 
assertEquals(l, leapfearCount (19051); 
assertEquals (1, leapYearCount | 
assertEquals (1, leapiearCount!1907]); 
assertEquals2, lespiearCount 1908) ); 
sertEquals (24, leapYesrCount (1999)] ; 
assertiquals (25, leapYearCount (2001) 
assertEquals(49, leapYearCount (2101) i: 
assertEquals (73, LeapiearCount (2201) 


assertEquals (97, leapYearCount (2301)1; 
assertEquals (122, leaprearCount (2401)); 


public void testIsLeapYear() throws Exception { 


public void testLeapYearCount() throws Exception i 


assertEquals(31, 
assertEquals (28, 
assertEquals (31, 
assertEquals (30, 
assertEquals (31, 
assertEquals (30, 
assertEquals (31, 
assertEquals (31, 
assertEquals (30, 
assertEquals (31, 
assertEquals (20, 
assertEquals (3. 
assertEquals 


public void testLastDayOfMonth(] throws Exception ( 


lastDayOfMonth (JANUARY, 19011); 
lastDayOfMonth (FEBRUARY, 1901) 
lastDayOfMonth (MARCH, 19011]; 
lastDayOtMonth (APRIL, 19C1)); 
lastDay0fMonth (MAY, 1901)) 
lastDayOfMonth (JUNE, 1901) 
lastDayOfMonth{JULY, 1901) 
lastDayOfNonth (AUGUST, 1901]]; 

lastDay0fMonth (SEPTEMBER, 1961)); 
lastDayOfMonth (OCTOBER, 1901)) 

lastDayOfMonth (NOVEMBER, 1901]]; 
lastDayOfMonth DECEMBER, 1901)); 
lastDayOfMonthtFEBRUARY, 1904) 


public void testAddDays() throws Exception { 


SerialDate newYears = dil, JANUARY, 1900); 
assertEquale(ó(2, JANUARY, 1900), addDays(1, newYears) ); 


SerialDate 
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275  assertEquals(d(l, FEBRUARY, 1500), addDays(31, newYearsi); 
assertEquals(d(l, JANUARY, 1301), addDays(365, newYears]]; 
assertEquals(d(31, DECEMBER, 1904), addDays(5 * 365, newYears]); 

‚ 


280  vrivate static SpreadsheetDate diint day, int month, int year) (return new 
SpreadsheerDate (day, month, year]:) 


public void testAddMonths(! throws Exception ( 

assertEqualsid(l, FEBRUARY, 1900), addMonths(1, díl, JANUARY, 190031); 
FEBRUARY, 1900), addMonthsil, d(3l, JANUARY, 1900:)); 
assertEquals(d(28, FEBRUARY, 1900], addMonths (1, d (TH 
assertEquals(d(28, FEBRUARY, 1900), addMonths(1, d(29, JANUARY, 19001) 
assertEquale(d(28, FEBRUARY, 1900), addMorthsil, (20, JANUARY, 190017); 
assertEquals(d(27, FEBRUARY, 1900), addMenths (1, 8027, JANUARY, 1900]; 


assertEqualsid(30, JUNE, 1900), addMonths(5, (31, JANUARY, 13001); 
assertEquals (d(30, JUNE, 1901), addMonths(17, d(31, JANUARY. 1900))): 


assertEqualsid(29, FEBRUARY, 1904), adiMonths (49, d(31, JANUARY, 19001)); 


) 


public void testadavears() throws Excepti 
assertEquals(d(1, JANUARY, 1901), addYearsil, dil, JANUARY, 1 
assertEquals(d(28, FEBRUARY, 1905), addYears(l, d(29, FEBRUAR 
assertBquals!d(26, FEBRUARY, 1905), addYears|l, dí28, FEBRUARY, 1904))); 
assertEqualsid(28, FEBRUARY, 1904), addYears(i, 4(28, FEBRUARY, 19030]; 
i 


public void testGetPrevicusDayOfWeek() throws Exception { 
assertEquals(d(24, FEBRUARY, 2006), gerPreviousDayGfWeek (FRIDAY, 2(1, MARCH, 2006)}): 
assertEquals(d(22, FEBRUARY, 2006), getPreviousDayOfWeek(WEDNESDAY, @(1, MARCH, 2005))); 
ertEquals(3(25, FEBRUARY, 2004), getPrevicusDayOfWeek (SUNDAY, d(3, MARCH, 2004)1); 
assertEqualsid(29, DECEMBER, 2004), getPreviousDayOfWeek(WEDNESDAY, di5, JANUARY, 200511); 


try d. 
getPrevicusDayOfWeek(-l, d(l, JANUARY, 20061); 
fail("Invalid day of week code should throw exception"); 


} catch (IllegalArgumentException e) | 
J 
public void testGetFellowingDayOfWeek() throws Exception { 
// — assertEguals(d(l, JANUARY, 2005),getFollowingDayOfWeek (SATURDAY, d(25. DECEMBER, 2004]]l; 


assertEquals(d(l, JANUARY, 2005), getFollowingDayOfWeek(SATURDAY, di26, DECEMBER, 20041); 
assertEquals(d(3, MARCH, 2004), getFollowingDayOfWeek(WEDNESDAY, di28, FEBRUARY, 20041]; 


uy ( 
getPollowingDayOfWeek(-1, (1, JANUARY, 2006)); 
fail('Invalid day of week code should throw exception"); 
) catch (IllegalArgumentException e) { 
Y 


public void testGetNearestDayOfWeek() throws Exception { 
assertEqualsid(16, APRIL, 2006), getNearestDayOfWeek(SUNDAY, di16, APRIL, 2006})); 
assertEqualsid(16, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(17, APRIL, 2006))); 
asserttquals(4(16, APRIL, 2006), getNearestDayOfWeek (SUNDAY, d(18, APRIL, 2006) 1); 
assertEqualsid(16, APRIL, 2006), getNearestDayOfWeek(SUNDAY, 9(19, APRIL, 2006))); 
assertEqualsíd(22, APRIL, 2006), getNearestDavOfWeek!SUNDAY, d(20, APRIL, 2006)]]; 
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assertEqualsid(23, APRIL, 2006), getNearestDayOfWeekiSUNDAY, 8120. APRIL, 2006)1); 
assertEqualsid(23, APRIL, 2006), getNearestDayOfWeek (SUNDAY, d(21, APRIL. 20061]; 
assertEqualsid(23, APRIL, 2006), getNearestDayOfWeek (SUNDAY. dí22, APRIL. 2006))); 


iitodo  assertEquals(d(17, APRIL, 2006), getNearestDayOfWeek(MONDAY, di15, APRIL, 2006)]); 
assertEquals(d(17, APRIL, 2006), getNearestDayOfwWeek(MONDAY, di17, APRIL. 20061)]; 
assertEguals!d(17, APRIL, 2 getNearestDayOfWeek(MONDAY, d(18, APRIL, 2006])); 
assertEqualsid(17, APRIL, getNearestDayOfWeek (MONDAY, d(19, APRIL. 2006))); 
assertEquals(d(17, APRIL, GetNearestDavOfWeek (MONDAY, (20, „ 20061)); 
assertEquaisid(24, APRIL, getNearestDayOfWeek (MONDAY, dl. 961); 
assertEqualsid(24, APRIL, getliearestDayOfWeek(MONDAY, 8122, . 20061] 


i! assertEquais(d(I8, APRIL, 2006), getNearestDayOfWaek (TUESDAY, di(16, APRIL, 200611); 
(| assertEquals(d(18, APRIL, 2006), getNearestDayOfWeekiTUESDAY, @(17, APRIL, 20061]; 


assertEquals(d(18, APRIL, 2006), getNearestDayOfWeek (TUESDAY, d(18, APRIL, 2006)}); 
assertEquals(dí18, APRIL, 2006), getNearestDayOfWeek(TUESDAY, 8119, APRIL, 2006))); 
assertEquals(d(16, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(2 L, 2006))): 
assertEquals(d(18, APRIL, 2006), getNearest Day0fWeek (TUESDAY, d(2 200611); 


assertEquals(di25. APRIL. 2006), getNearestDayOfWeek (TUESDAY, d(22, APRIL, 2006))); 


APRIL, 200611); 
, APRIL, 20061); 


assertEquais(dil9, APRIL, 2006), getNearestDayOfWeek (WEDNESDAY, d(16 
assertEquals(a(19, APRIL, 2006), getNearestDayOfWeek (WEDNESDA: 
assertEqualsid(19, APRIL. 2006), getNearestDayOfWeek (WEDNESDAY, 2118, APRIL, 20061) 
assertEqualsid(19, APRIL, 2006), getNearestDayOfWeek (WEDNESDAY, @(19, APRIL, 20061)); 
assertEqualeidi19, APRIL. 2006), getNearestDayOfWeek!WEDNESDAY, d(20, APRIL. 20061)): 
assertEquals(d(19, APRIL, 2006), getNearestDayOfWeekiWEDNESDAY. d(21, APETL, 2006))): 
asaertEquals(d(19, APRIL, 2006), getNearestDayOfWeek|WEDNESDAY, d(22, APRIL. 200611); 


assertEqualsid(13, APRIL, 20061, getNearestDayOfWeek|THURSDAY, d(16, APRIL, 200611); 
assertEqualsid(20, APRIL, 2006), getNearestDayOfWeek|THURSDAY, d(17, APRIL, 2006)1): 
assertEquals(d(20, APRIL, 2006), getNearestDayOfWeek (THURSDAY, (18, APRIL, 200611); 
assertEquals(d(20, APRIL, 2006), getNearestDayOfWeekiTHURSDAY, 1(19. APRIL, 20061); 
assertkquals(d(20, APRIL, 2006), getNearestDayOfWeek (THURSDAY, 4(20, APRIL, 2006))); 
assertEquals (d(20, APRIL. 2006), getNearestDayOfWeek (THURSDAY, @(21. APRIL, 2006)]): 
asserrEquals(d(20, APRIL, 20061, getNearestDayOfWeek (THURSDAY, d(22, APRIL, 2006))); 


assertEquals(d(14, APRIL, 2006), getNearestDayOfheek (FRIDAY, d(16, APRIL, 2006)]); 
assertEquals(d(14, APRIL, 2006), getNearestDayOtWeek(FRIDAY, d(17, APRIL, 2006))); 
assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(18, APRIL, 2006))); 
assertEquals(d(21, APRIL, 2006), getNearestDayOfheek (FRIDAY, d(19, APRIL, 2006))); 
assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, di20, APRIL, 2006))); 


assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, di21, APRIL, 2006)]]: 
assertEqualsid(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, 3122, APRIL. 2006)]]; 


assertEquals(d(15, APRIL, 2006), getNearestDayOfWeek(SATURDAY, 1116, APRIL, 2006)}); 
assertEquals (d(15, APRIL, 2006), getNearestDayOfWeek (SATURDAY, d(17, APRIL, 200611); 
assertEquals(d(15, APRIL, 2006), getNearestDayOfWeek (SATURDAY, d(18, APRIL, 2006))} 
assertEquals(d(22, APRIL, 2006), getNearestDayOtWeek (SATURDAY, di13, APRIL, 2006)}) 
assertEquals (d(22, AERIL, 2006), getNearestDayOfWeek (SATURDAY, 4(29, AFRIL, 2006)1); 
assertEquals(d(22, APRIL, 2006), getNearestDayOfWeek (SATURDAY, d(21, APRIL, 20061]); 
assertEquals (d(22, APRIL. 2006), getNearestDayOfWeek (SATURDAY, 4122, APRIL, 2006))}; 


uy { 
getNearestDayOfWeeki-1, dil, JANUARY, 2006)); 
faili'Invalid day of week code should throw exception") 
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public void testEndofCurrentMonthi) throws Exception ( 
SerialDate d = SerialDate.createInstence(2); 
assertEquals (d(31, JANUARY, 2006), é.getEndOfCurrentMonth(d(l, JANUARY, 2006)]); 
assertEquals(d(28, FEBRUARY, 2006), d.getEndOfCurrentMonthidil, FEBRUARY, 2006))]; 
assertEquals (8121, MARCH, 2006), d.getPndOfCurrentMonthid(1, MARCH, 2006))]; 
assertEquals(d(36, APRIL, 2006), d.getEndofCurrentMonth(d(1, APRIL, 2006)i]; 
assertEquals(d(31, MAY, 2006), d.getEndOfCurrentMonth(d(1, MAY, 
assertEquals(d(36. JUNE, 2006), d.getEndOfCurrentMonth(d!i, JUNE, 

JULY, 2006), d.getEndOfCurrentMonthid(l, JULY, 

AUGUST, 2006), d.getEndOfCurrentMonthidil, AUGUST, 2006))); 
assertEquals (9130, SEPTEMBER, 2006), d.getEndOiCurrentMonthidil, SEPTEMBER, 2006) 1); 
assercEquals(d(31, OCTOBER, 2006), d.getzndOfCurrentMonth(d(1, OCTOBER, 2606) 1); 
assertEquals (d(30, NOVEMBER, 2006), d.gerEndOfCurrentMonth!d(1, NOVEMBER, 2006) 1); 
assertEquals (d(31, DECEMBER, 2006), d.gecEndOfCurrentMonth(d(1, DECEMBER, 2006)]]; 
assertEquals (d(29, FEBRUARY, 2008), d.getEndofcurrentMonth(d(i, FEBRUARY, 2008))); 

) 


public void testWeekInMonthToString() throws Exception { 
assertEquals ("First * weekinMonthTostring (FIRST, WEEK, IN MONTH) 
assertEquals (*Second" ,ueekInNonthToString(SECOND WEEK IN MONTH)!; 
assertEquals ( "Third" weekInMonthToString(THIRD WEEK IN MONTEI } ; 
assertEquals (*Fourzh* ,weskInMonchTostring!FOUPTH WEEK. TN MONTH) ); 
assertEquals ("Last*, weekTnMonthToString (LAST WEEK IN MONTH)]; 


417 /;todo try ( 


418 // weekInMonthToString|-1); 
419 / faili'Invalid week code should throw exception"); 
420 / ) catch (IllegalArgumentException ei ( 


Ё 


} 


public void tescRelativeToString(! throws Exception ( 
issert Bqua]s |"Preceding* , relativeToString (PRECEDING) ) ; 


assercEquals i "Nearest ” ‚, relativeToString NEAREST) ) ; 
assertEquals! "Following", relativeToString(FOLLOWING)); 
429 /jtodo туї 
430 / relat iveToString(-1000); 
431 77 faili*Invalid relative code should throw exception"); 
432 / } catch (Il legaiargumentException e) ( 
433 7 i 
431 + 
435 


436 public void testCreateInstanceFromDDMMYYY() throws Exception і 
137 — SerialDate date = createInstance(l, JANUARY, 1900); 

438 assertEquals (1,dace.getDayOfMonth(} |; 

439 assertEquals (JANUARY, date.getMonch! |) ; 

440 assertEquals(1900,date.gerYYYv()); 

441 assertEquals!2,date.toSer1al(]); 

w 1 


£44 public void testCreateInstanceFromSerial() throws Exception { 
445 assertEqualsid(l, JANUARY, 1900),createlnstance(2]]: 

446 — assertEquals{d(1, JANUARY, 1901), createInstance!367]]; 
A) 


443 public void testCreateinstancePromjavaDate() throws Exception [ 
450 — assertEquals(d(l, JANUARY, 1900), 

createInstance (new GregorianCalendar (1900, 0,1) .gerTime() +); 
451 assertEquala(d(1, JANUARY, 2006), 

ereateInstance|new Gregor ianCalendar (2006,0),1).aetTime(}}): 
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452 1 

453 

454 public static void mainístringi] args) { 

455 junit.textui.TestRunner.run (BobsSerialDateTest .ciass; ; 
456 | 

457 } 


Listing B-5 


i 
i 


a free general purpose class library for the Java(tm) platform 


(C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 


Project Info: http://www. jfree.org/jcommon/index. html 


free software; you can redistribute it and/or modify it 
cf the GNU Lesser General Public License as published by 
Foundation; either version 2.1 of the License, or 
rsion. 


the Free Softwa: 
iat your option) any later 


This library is distributed in the hope that it will be usefui, bur 
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
or FITNESS FOR A PARTICULAR PURPOSE, See the SNU Lesser General Public 
License for more details. 


You should have received a copy of the GNU Lesser General Public 

License along with this library; if not, write to the Free Software 
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA. 


[Java is a trademark or registered trademark of Sun Microsystems, Inc. 
in the United States and other countries.] 


adeheetDate, java 
(C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 


Original Author 
Contributor (si: 


David Gilbert (for Object Refinery Limited); 


Std: SpreadsheetDate. јаүа,у 1.8 2005/11/03 09:25:39 mungady Exp $ 


11-Oct-2001 
05-Nov-2001 
12-Nov-2001 


version 1 (DG); 

Added getDescription() and setDescription() methods (DG); 

Changed name from ExcelDate. java to SpreadsheetDate. java (DG); 

Fixed a bug in calculating day, month and year from serial 

number (DC); 

24-Jan-2002 : Fixed a bug in calculating the serial number from the day 
month and year. Thanks to Trevor Hills for the report (DG); 


S-May-2002 : Added equals (Object) method (SourceForge ID 556350) DG); 
03-Oct-2002 : Fixed errors reported by Checkstyle (D3); 

13-Mar-2003 : Implemented Serializable (05); 

04-Sep-2003 : Completed isInRange() methods (DG); 

95-Sep-2003 : Implemented Comparable (DG); 


21-Oct-2003 : Added kashCode() method (DG); 
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55 package org.jfree.date; 
56 

57 import javá.util.Calendar; 
import java.util.Date; 


Represents à date using an integer, in a similar fashion to che 
implementation in Microsoft Excel. The range of dates supported is 


1-Јап-1900 to 31-Dec-9939, 

<P> 

Be aware that there is a deliberate bug in Excel that recognises the year 
1900 as a leap year when in fact it is not a leap year. You can find more 
information on the Microsoft website in article 0181370: 


support microsoft .com/ support /kbjarticles/0181:3/70.asp 


ases the convention that 1-Jan-1900 = 1. This class uses the 
convention 1-Jan-1900 = 2. 
The result is that the day number in this 
Excel figure for January and February 1900.. 
day (29-Feb-1900 which does not actually exis! 
the day numbers wiil match. 


lass will be different to the 
but then Excel adds in an extra 
1 and from that point forward 


author David Gilbert 


public class SpreadsheetDate extends SerialDate ( 


n. 
long serialversionUID = -203958 


53744544611: 


me 
* The day number 
* 2958465) . 

* 

private int serial; 


-1900 = 2, 2-Јап-1900 = 3, ..., 31-Dec-9999 = 


/** The day of the month (1 te 28, 29, 30 or 31 depending on che month). */ 
private int day: 


{** The month of the year (2 to 12). */ 
private int month; 


** The year (1900 to 3399). */ 
private int year; 


!** An optional description for the date. */ 
private String description; 


* Creates а new date instance. 

* @param day che day (in the range 1 to 28/29/30/31). 
* éparam month the month (in the range 1 to 12 
* @param year rhe year (in the range 1900 to 9999). 


public SpreadsheetDate(final int day, final int month, final inr year) [ 
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nr if ((year >= 1900) аё lyear <= 9399)) | 

113 Lhis.year = year; 

in 1 

lis else | 

116 throw new TllegalArgunent Exception( 

117 "The ‘year’ argument must be in range 1900 to 9999." 
ua iz 

119 H 


if (imonth >= MonchConstanes, JANUARY) 
&& (month <= MonthConstants.DECEMBERi) { 
this.ronth - month; 


eise | 
throw new IllegalargumentExcept ion| 
"The 'month' argument must be in the range 1 to 12." 


1) && (day <= Serialuate lastDayOfMonth (month, yearjl! ( 
day - day; 


throw new IllegalArgumentException(*Invalid ‘day’ argument."j; 


/ the serial number needs to be sy 'onised with the day-month-year... 
this.serial = calcSerialiday, month. year!; 


this;description = null; 


* Standard constructor - creates a new date object representing the 
* specified day number (which should be in the range 2 to 2958465. 


* Qparam serial the serial number for the 4 


public SpreadsheetDateifinal int serial) { 


y (ranges 2 to 2958465). 


if ((serial >= SERIAL ТОНЕВ BOUND! && (serial <= SERIAL UPPER BOUND!! { 


JaiArgunentEXceptioni 
"Spreadsheettote: Serial must be in range 2 to 2958465. 


the day-month-year needs to be synchronised with the serial number... 
calcDayMonthyear ‘1 


8 the description that is attached to the date. It is not 
* required that a date have a description, but for some applications it 


* is useful. 
* éreturn The description that is attached to the date. 
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public String getDescription() { 
return this.description; 
) 
8 * seta the description for the date. 
9 * 
130 * éparam description the description for this date «code»mulle/code» 
181 * permitted). 
182 ay 
183 public void setDescriptionifinal string description) | 
184 chis.deseription = description; 
185 \ 
186 


+ Returns che serial number for the date, whel 
* (this corres 
* Excel for 
* @retura The s 
public int teSerial!) 1 

return this.serial; 


1 January 1900 = 
nds, almost, to the numbering system used in Microsoft 
dows and Lotus 1-2-3). 


1 number of this date. 


* Returns a «code»java.util.Date«/code» equivalent to this date. 


* Greturn The date. 
public Dare toDatel] 1 
final Calendar calendar = Calendar .gerInstancei) ; 
calendar .set (get YZVY(j, getMonth() - 1, getDayOfMonth(), 0, 0. 0); 
return calendar.getTime() ; 


* Returns the year (assume à valid range of 1900 to 3993). 


* return The year. 


public int getYYYY[) i 
return this.year: 


* Returns the month (January = l, Februa: 


* éreturn The month of the year. 
public int gecMonth() | 
this.month; 


2, March = 3), 


1 
* Returns the day of the month. 


+ @return The day of the month. 
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public int getDayOfMonthi) | 
return this.dar 


* Returns а code representing the day of the week. 
* «p 

+ The codes are defined in the (link SerialDate} class as 
* «code»SUNDAY«/code», <cede>MONDAY</code>, <code>TUESDA! 


NESDAY</code>, «code»THURSDAY«/code», «code»FRIDAY«/code». and 
<code>SATURDAY< / code» . 


üreturn A code representing the day of the week. 
public int getDayofWeeki] { 
rerum (this.serial + 6) € 7 +1; 


T 
* Tests the equality of this date with an arbitrary obje 

+ > 

* This method wili return true ONLY if the object is an instance of the 
* (8link SerialDate] base class, and it represents the same day as this 
+ {Glink SpreadsheerDare}. 

* param object the object to compare (<codesnull</code> permitted. 

* @return А boolean. 


public boolean equals 


al Object object} 


if (object insti É Serialbate) ( 
al SerialDate s = (SerialDate) object; 
rn (s.toSerial() == this.toSeriali}); 


E 


) 
eise { 
return false; 


+ Returns a hash code for this object instance 


* @return A hash code. 
public int hashCode) { 
return toserial(); 


Returns the difference lin days) between this date and the specified 
'other' date. 


Gparam other the date being compared to. 


this date and the specified 
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public int compareifimal SerialDate other! { 
return this.serial - other.toSerial(); 


* implements the method required by the Comparable interface. 
* aparam other the other object (usually another SerialDate]. 
+ return A negative integer, zero, 

t as less than, equal te, or 
public int compareTo(final Object other) ( 

return compare((SerialDate) other); 
} 
m 


+ Returns true if this Serialfate represents the same date as the 
* specified Serialdate. 


aparan other the date being compared to, 


code» if this Seriaia 
Serialbate. 


e represents the same date as 


* @return «code»true. 
, the specif 


public boolean ison(final SerialDate other) { 
return (this.serial == ocher.toSerial(j): 


Returns true if this SerialDate represents an earlier date compared to 
the specified SerialDate, 


G@return <code>truec/cade> if this SerialDate represents an earlier date 
compared to the specified SerialDate. 


* Gparam otker che date being compared to. 


public boolean isBeforeifinal SerialDate other) ( 
return ithis.serial < other.toSeriall]); 
j 


turns true if this SertalDate represents the same date as the 
ecified SerialDate. 


@recurn «code>truec/code> if this SerialDate represents the same date 


* éparam other the date being compared to. 
? as the specified SeriaiDate. 


(final SerialDate other) { 


r.toSerial(1); 


public boolean isOnOrBefor 
return ithis.serial 


* Returns true if this SerialDate represents the same date as the 
specified SerialDare. 


Gparam other the date being compared to. 
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* Greturn <codestruec‘code> if this SerialDate represents the same date 
hi as the specified SeriaiDate. 
public boolean isAfter(final SerialDate other) ( 

return (this.serial > ocher.togeriali)); 


) 


ums true i 
specified Seri 


s SerialDate represents the same date as the 
Date. 


* 
* Sparam other the date being compared to. 
* éreturn «code»truec/code» if this SerialDate represents the same date ав 
ж the specified SerialDate. 
+ 
public boolean isOnOrAfter(final SerialDate other! ( 

return (this.serial >= other .toSerial()); 


* Returns <code>true<‘code> if this (&link Ser1alDace) is within the 


specified range (INCLUSIVE). The date order of dl and d is not 
important. 


+ &param dl а boundary date for the range. 
* üparam d2 the other boundary date fcr the range. 


&return A boolean. 


public boolean isInRangeif: 
return isInRange(dl, 42, $ 


SerialDate di, final SerialDate 62) ( 
*ialDate.INCLUDE BOTH); 


} 


Returns true if this SerialDate is within the specified range (caller 
specifies whether or not the end-points are included). The order of di 
and d2 is not important. 


= &param dl one boundary date for the range. 

* Gparam d2 a second boundary date for the range. 

* éperam include = code that controls whether or not the start and end 
Ы dares аге included in the range. 


return «code>trusc/ code: 
range. 


if this SerialDate is within the spe 


public boolean isInRange(final SerialDate di, final SerialDate dê, 
final int include) ( 

toSerial(); 

int d2.tcSerial(); 

int Math.niní(sl, 

int end = Marh.maxís!, 92); 


int sl 


n 


int s = toSeriali); 

if (include == SerialDate. INCLUDE BOTI 
return (s >= start && 5 <= end); 

H 


else if (include == SerialDate. INCLUDE FIRST) | 
return (8 >= Start && 8 « endi; 
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2 i - 
412 \ 
43 else if {include SerialDate. INCLUDE SECOND) { 
4M return (s > start && s <= endi; 


! 
else { 
return (s > start &k s < end): 


Calculate the serial number from the day, monii 
<P> 
1-Jan-1900 = 2. 


and year. 


Gparam m the month. 

428 üparam y che year. 

429 

430 Greturn the serial number from the day, month and year. 


* üparam а the day. 


caleSeriallfinal int d, final ant я, final int y) [ 

у с ity - 1500) * 365) + Serialpate.leapYearcount(y - li; 
434 int am = SerialDace.ASGREGATE, DAYS TO END CF PRECEDING MONTHImI; 
435 if (m > MonthConstants. FEBRUARY) { 


if (SerialDate.isLespYear(y]] { 
тп = on + 


final int dd = d; 
return yy + mm + dd + 1; 
) 


* Calculate the day, month and year from the serial number. 
private void calcDayMonthYear() { 


1! get the year from the serial date 

final int days = this.serial - SERIAL LOWER, EOUND; 

2 overestimated because we ignored leap days 

final inc overestimazedYYYY = 1900 + (days / 365): 

final int leaps = SerialDate. leapYearCount (overestimatedYYYY) ; 
ys = days - leap 

| underestimated because we overest 

matedYYYY = 1900 + (nonleapdays + 


if (underestizatedYYYY == overestimatedYYYY) ( 
this.year = wnderescimatedYYYY; 


! 
else { 
int 581 = calcSerialil, 1, underestimatedYYYY]; 
while (ssl <= this.serial) ( 
underestimatedYry! erestimatedYYYY + 1: 
= calcseri underestimatediYYY); 


this.year = underestimatedYYYY - 


) 


final int ss2 = calcSerialll, 1, this.yeari; 


incl) daysToEndOfPrecedingMonth 
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SpreadsheetDate. java 
+73 = AGGREGATE DAYS TO END OF PRECEDING MONTH; 
474 
475 if (isLeaprear(this.year)) ( 
476 daysTOEndoFPrecedingMonth 
477 = LEAP YEAR AGGREGATE, DAYS. TO END OF. PRECEDING MONTE; 
478 ) 
479 
480 get the month from the serial date 
E in m = 1; 
482 int sss = 552 + daysToEndOfPrecedingMonth[mm] - 
183 while (sss < tkis.seriali { 
E mm = mm + 1; 
485 sss = 882 + daysToEndOfPrec 
486 ] 
487 this.month = mà - 1; 
EJ 
489 what's left is a(+1); 
490 this.day = this.serial - ss2 
E = daysTomd0fPrecedingMonth|this.month) + 1; 
E 
493 
4 
495} 


Listagem B-6 
RelativeDayOfWeekRule.java 


| 


JCommon : а free general purpose class library for the Java(tm) pl 


2) Copyright 2000-3005, by Object Refinery Limited and Contributors. 


p: / ‘www. free. org, jconmon/index.hrmi 


This library is free software; you can redistribute it and/or modify it 
under the terms of the GNU Lesser General Public License as published by 


the Free Software Foundation; either versicn 2.1 of the License, or 
lat your option! any later version. 


This library is distributed in the hope that it will be useful, but 
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILT 
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 
License for more derail 


You should have received a copy of the GNU Lesser General Public 
nse along with this iibrary; if not, write to the Free Software 
Foundation, Inc., 51 Franklin Streer, Fifth Floor, Boston, MA 02110-1301, 
USA, 


(Java is a trademark or registered trademark of Sun Microsystems, Inc. 
in the United States and other countries.] 


RelativeDayOfWeekRule. ja: 


(С) Copyright 2000-2003, by Object Refinery Limited and Contributors, 


Original Author: David Gilbert (for Object Refinery Limited); 
ntribetor(s): =; 


. 
` 
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Listagem B-6 (continuação) 
RelativeDayOfWeekRule.java 


Sid: RelativeDayOfWeekRule.java,v 1. 2005/11/16 15:58:40 taqua Exp S 


Changes (from 26-Oct-2001) 


Changed package to com. jrefin 
: Fixed errors reported by Chec 


yle (DG); 


«date; 


An annual date rule that returns a date for each year based on ia) а 
reference rule; (b) a day of the week; and (с) a selection parameter 
(SerialDate. PRECEDING, SerialDate.NEAREST. SerialDate. FOLLOWING). 

<P> 

For example, Good Friday can be specified as 'the Friday PRECEDING Easter 
Sunday’. 


* @author David Gilbert 


RelativeDayOfWeekRule extends AnnualDateRule 


public clas: 


{** à reference to che annual date rule on which this rule is base 
private AnnualDateRule subrule; 


* The day of the week (SerialDate.MONDAY, SeriálDate. TUESDAY, and so оп). 


6 “ 
$4 private int dayOfWeek; 


/** Specifies which day of the week IPPECEDING, NEAREST or FOLLOWING). */ 
57 private int relative; 


* Default constructor - builds e rule for the Monday following 1 January. 


public RelativeDayOfWeekRule() ( 
this(new DayAndMonthRule(), SerialDate.MONDAY. SerialDate.FOLLOWINJ); 
\ 


* Standard constructor - builds rule based on the supplied sub-rule. 
* Gparam subrule the rule that determines the reference date. 
* param dayOfWeek the day-of-the-week relative to the reference date. 
* @param relative indicates *which* da the-week (preceding. nearest 
* or following). 
public RelativeDayOfWeekRuleifinal AnnualDateRule subrule, 
final int dayOfWeek, final int relative) { 
this.subrule - subrule; 
this.dayOfWeek = dayOfWeek: 
rhis.relative = relative; 


) 


* Returns the sub-rule (also called the reference rule), 
* éreturn The annual date rule that determines the reference date for tl 
3 rule. 
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Listagem B-6 (continuacáo) 
RelativeDayOfWeekRule.java 
E m" 
x + Returns the sub-rule {alzo called the reference rule). 
E * 
E * @return The annual date rule that determines the reference date for this 
35 . rule. 
% + 
397 public AnnualDatePule getsubrule(i | 
98 turn this.subrule: 
» 
100 
101 " 
102 * Sets the sub-rule. 
103 * 
104 * Gparam subrule the annual date rule that determines the reference date 
105 M for this rule. 
106 Ы 
107 publie void setSubrule(final AnnualDateRule subrule) ( 
108 this.subrule 
i5 } 
110 
111 f 
12 * Returns the day-cf-the-week for this rule. 
113 + 
in * @return the day-of-the-week for this rule. 
115 * 
116 public int getDayOfWeek() | 
n? return this.dayOfWeek: 


* Returns the ‘relative’ attribute, that determines *which 
* day-of-the-week we are interested in (SerialDate. PRECEDING, 


SerialDate.NEAREST or SerialDate. FOLLOWING) . 


return attribute. 


public int 
return 


* Sets the ‘relative’ attribute (SerialDate. PRECEDING, SerialDete.NEAREST, 
* SerialDate. FOLLOWING) . 
* üparam relative determines "whick" day-cf-the-week is selected by thus 
+ rule, 
public void setRelativeifinal int relative) { 

this.relative = relativ 
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Listagem B-6 (continuação) 
RelativeDayOfWeekRule.java 

152 a" 

153 * Creates a clone of this rule. 

154 * 

155 * Grecum a clone of this rule. 

156 + 

157 * üthrows CloneNotSupportedException this should never happen. 
155 E 

159 [ 
160 

161 


üparam year rhe year (1900 &lt;= 


«code»null«/code»). 


* @return The date generated by the rule for the given year (possibly 


public SerialDate cetpate(final int year) { 


! check argument... 
if l(year < SerialDate.MINIMUM YEAR SUPPORTED) 
|i (year > SerialDate.MAXIMUM YEAR SUDPORTED)) ( 
throw new lliegalkrgumentExcepLion( 
"RelariveDayOfWeekRule.cetDate(]: year outside valid range." 


/ calculate the dati 
Seria result 
final SerielDate bi 


ull; 
= this.subrule.getDate (year); 


if ibase t= null! ( 
switch ithis.relative) ( 
case (SerialDate.PRECEDING! : 
result = SerialDate.getPreviousDayOfWeek thi s. dayOfWeek, 
base); 


eak; 

alDate.NEAREST] : 

t = SerialDate.gettearestDayStweek (this. 
base); 


break; 
case (SerialDate. FOLLOWING) + 
result = SerialDate.getFollowingDayOfWeek (this. dayOfWeek, 
basel; 
break; 
default 
break; 


j 
return result; 
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Listagem B-7 (continuação) 
DayDate.java (Final) 


package org. j£rée.date: 


38 
33 import java.io.Serializable; 
40 import java.util.*; 


Ar abstract class that represents immutable dates with a precision of 
one day. The implementation will map each date to an integer that 
represents an ordinal number of days fron some fixed origin. 


Why not just use java.util.Date? We will, when ic makes sense. At times, 
java.util.Date can be *toc* precise - it represents an instant in time. 
accurate to 1/1008th of a second (with the date itself depending on the 
time-zone). Sometimes we just want to represent a particular day (e.g. 21 
January 2015) without concerning ourselves about the time of day, or th 
time-zone, or anything else. That's what we've defined DayDate for. 


Use DayDateFactory.makeDate to create an instance. 


Sauthor David Gilbert 
@author Robert C. Martin did a lot of refactoring. 


public abstract class DayDate implements Comparable, Serializable ( 
public abstract int getOrdinalDay(): 
public abstract int getYear(); 
public abstract Month gerMonth(!; 
public abstract int setDayOfMenthi]; 


protected abstract Day getDayOfWeekPorürdiralzeroi!; 


public DayDate plusDays(int days) ( 
return DayDateFactory .makeDate (getOrdinalDay() + days); 


public DayDate plusMonths int months) { 
int thisMonthAsOrdinal = getMonth().toInt|) - Month. JANUARY.toInt ij; 
int thisMonthAndvearasOrdinal = 12 * getYeari) + thisMonthAsOrdinal; 
int resultMonthAndvearAsOrdinal = thisMonthAndYearAsOrdinal + months; 
int resultYear = resultMonthAndYearAsOrdinal / 12 
int resultMonthAsOrdimal = resultMonthAndYearAsOrdinal 4 12 + Month.JANUARY.toInt(); 
Month resultMonth = Month. fromint resultMonthAsOrdinal; 
int resultDay = correctLastDayOfMonth (getDayOfMonth(}, resultMonth, resultYear); 
return DayDateFactory.nakeDate(resultDay, resultMonth, resultYear); 

) 


public DayDare plusvearsiint years) ( 

int resultYear = getvear() + year 
int resultDay = correctLastDayOtMonth!getDayGfMonth(], getMenthi), resultrear); 
return DayDateFactory sakeDate(resultDay, getMonth(), resultiear); 


private int correctLastDayOfMonth(int day, Month month, int year) { 
ant lastDayOfMonth = DateUtil.lastDayOfMonth(month, year); 
if (day > lastDayOfMonth) 
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Listagem B-7 (continuação) 
DayDate. java (Final) 


32 
°з 


day = lastDayOfMonch; 
return day; 


public DayDate getPreviousDayOfWeek (Day targetDayOfweek) | 
int offsetTotarget = targetDayOfWeek.toInt() - getDayOfWeek().teInt(); 
if (offeetToTarget >= 2) 
offsetToTarget 
return plusDaysioffsetToTarget 
i 


public DayDate getFollowingDayOfWeek(Day targetDayOfWeek) { 
int ofisetToTarget = LargetDayOfWeek.toIntí) - getDayOfWeek() .toInt(); 
if [offsetToTarget <= 0) 
ofisetToTarget 
return plusDays (offset ToTarget |; 


public DayDate getNearestDayOfWeek (Day targerDayOfWeek! { 
int offsetToThisWesksTarget = targetDayOfWeek.toint () - getDayOfWeeki).toint|); 
int offsetToFutureTarget = (offsetToThisWeeksTarget + 7) & 7; 
int offsecToPreviousTarget = offsetToFutureTarget 


if (offsetToFutureTarget > 3) 
return plusDays (offset ToPreviousTarget) ; 
else 
return plusDays (offsetToFutureTarger) ; 
+ 


public DayDate cetEndotMonth() | 
Month month = getMonth!; 
int year 
int lastDay = -lastDayOfMonth (month, увагі; 
return Daylateractory .makeDate (iastDay, month. year); 


public Date toDate() ( 
final Calendar calendar = Calendar.getInetance(); 
int ordinalMonth = getMonth().:oInt() - Month. JANUARY.toInt (i 
calendar.set(getYear(), ordinalMonth, gecDayOfMonth(), 0, 0, 0); 
return calendar .getTime(); 

n 


public String toString!) 4 
return String.formati*$02d-is-td", getDayOfMonthi?, getMonth(), getYeari]]; 


public Day getDayOfWeeki) | 
Day startingDay = getDayOfWeekForOrdinalZero(); 
int startingOffeet = startingDay.toInt() - Day.SUNDAY.toInL(); 
int ordinal0fDayOfWeek = igetOrdinalDay!) + startingOffset) & 7; 
return Day. fromint [crdinalOfDayOfWeek + Day.SUNDAY.toInt!)); 


p incetDayDate date) { 
return getordinalDay() - date.getOrdinalDay(): 


public boolean isOn(DayDate other) | 
return getOrdinaiDay() == other.getOrdinali 
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Listagem B-7 (continuacáo) 
DayDate.java (Final) 


public boolean isBeforeiDayDate other) { 
return getOrdinaiDay() < other.getürdinalDayi]; 


public boolean isOnOrBeforeibayDate other) { 
return getOrdinalDay() <= other.getOrdinalDay|); 
П 


public boolean isAfter(DayDate other! { 
return getOrdinalDay!) > ather.gerOrdinalDay() ; 
i 
public boolean isQnorAfteriDayDate other) { 
return getOrdinalDay() >= other.getOrdinalDay]: 


public boolean isInRange(DayDate dl, DayDate 22) | 
return isInRange(dl, d2, Dateinterval.CLOSED): 


) 


public boolean isInRanzeiDayDete dl, DayDate d2, DateInterval interval) | 
int left = Math.ninidl.getürdinalDay), 42 t 
int right = Math.max(dl.getOrdinalDay(}, d2 
return interval.isinigerOrdinalDay|), left, right}; 


Listagem B-8 
Month.java (Final) 


package org. jfree.date; 
import java. text .DateFormatSynbols; 


1 
2 
3 
5 public enum Month ( 
$  JANUARY(1), FEBRUARY (2), MARCH(3), 
7  APRIL(4), МАҮ(5), JUNE(6) , 
8  JULY(), AUGUSTIS),  SEPTEMBER(S), 
3 OCTOBER(10), NOVEMBER (11) , DECEMBER (12) ; 
private static DateFormatSymbols dateFormat Symbols = new DateFormatSymbo!si]; 
private static final int{] LAST DAY OF MONTH 

10, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}: 


private int index; 


Monthiint index) { 
this. index = index; 


public static Month fromint (int monthindex) ( 
for iMonth m : Month.values()] { 
if (m.inde monthIndex) 
return 


1 
throw new Illega: 
) 


qumentExceptioni"Invalid month index * + monthIndex) ; 


public int lastDayi) ( 
return LAST. DAY OF MONTH[index]; 
1 
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Listagem B-8 (continuação) 
Month.java (Final) 


32 public int quarter() { 

52 return 1 + (index - 1) 

3 ) 

35 

36 public String toString() | 

Y return daceFormatSymbois.getMonths (i [index - 1]: 


ublic String toshertstring() | 
return dateFormarSynbols.getShortMonths() {index - 1]; 


public static Month parse(String si ( 
e = s.trim(); 
for (Month m nth.values()) 
if (m.matchesis)) 
return m; 


try ( 
return fromint(Integer.parseIntis]]; 


} 


ch (NumberFormatException е} (] 
54 throw new TllegalàrgumentExceptioni"Invalid month * + 8); 
55 + 


57 private boolean matches(String s) | 
53 return s.equalsIgnoreCase(toString()) || 


E] z.equalsIgnorecase (toShorttring!] ) ; 
60 } 

61 

62 public int totti) | 

63 return index; 

& } 

[3 
Listagem B-9 


Day.java (Final) 


package org. jfree.date: 


endar; 
text .DaceFormacSymbols; 


uti 


NDAY (Calendar .MONDAY) , 
TUESDAY (Calendar. 
8 — WEDNESDAY (Calendar. WEDNESDAY) . 
10 THURSDAY (Calendar. THURSDAY) , 
11 FRIDAY (Calendar. FRIDAY), 
12 SATURDAY (Calendar. SATURDAY) , 
13 SUNDAY (Calendar. SUNDAY) ; 


4 
5 
é public enum Day ( 
8 
9 


a 

15 ivate index; 

lé private FormatSymbols dateSymbols = new DateFormatSymbolsi); 
D 

18  Daylint 

19 index = day; 

20 ) 
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Listagem B-9 (continuação) 
Day.java (Final) 


public stat 
for (Day d 
f (d index ех) 
return d; 
throw пем IilegalArcumentException( 
String.formati*lllegal day index: àd.*, index): 


emint (int index) thro 


legalArgument xcept ion į 


i 


public static Day parseiString s) throws IllegalàrgumentException | 


String[j weekDzyName: 


dateSymbols .getWeekd; 
8 = s.ceimt); 
for iDay day : Day.values 
if (a.equalsIgnoreCsse (shortWeekdayNames[day.index]) || 
ndex}}) { 


throw new IllegalArgument Except iont 
String. format ("ts is not a valid weekday string", 51); 


public String tostringi) | 

return datesymbols.getwWeekdays|) [index] ; 
public int tofnt() É 

return index 


1 


Listagem В-10 
DateInterval.java (Final) 


1 package orc.jfree.date; 


public enum DateTnterval ( 
OPEN f 
i int right) ( 


int right) ( 


int right) 


return d > left && d <= right; 


) 


L 
CLOSED { 
public boolean isIntint d, int left, int right) | 
return d >= left à& d <= right; 
i 
н 


public abstract boolean isIn(int d, int left, int right); 
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Listagem B-11 
WeekInMonth.java (Final) 


1 package org. jfree.d: 


3 public enum WeekInMonth į 
FIRST(1!, SECOND(2), THIRD(3), FOURTH(4), LAST(O); 
private final int index; 


4 
5 
7  WeekInMonth(int indexi 
8 
B 
1 


this.index - index; 
x 

ll public int tomnti) | 
12 turn index; 

n 

м) 
Listagem B-12 


WeekdayRange. java (Final) 


package org. jfree.date: 


public enum WeekdayBange { 
LAST, NEAREST, NEXT 


Listagem B-13 
DateUtil.java (Final) 


1 package org, jfree.date; 

3 import java.text dateFormatSymbols: 

4 

5 public class DateUtil ( 

Б private static DateFormatSynbols dateFormatSymbols = new DatePorzatSymbols|!; 
B public static String[] getMonthNames() | 

9 return dateFormatSymbols.getMonths |) ; 

0 } 

m 

12 public static boolean isLeapyear (int year) ( 
13 boolean fourth = year à 4 == 0; 

1à boolean hundredth = year $ 100 


15 boolean fourHundredch = year & 405 Я 

lê return fourth && (!hundredth || four#undredthi; 
7 } 

18 


19 public static int lastDavOfMonth(Month month, int year) { 
20 if (month == Month.FEBRUARY && isLeapYear (year) | 


1 return month.lastDay|) + 1; 

2 else 

E] return month. lastDay(); 

A) 

25 

26 public static int ieapYearCount (int year] { 
27 leap 96) 24 


at 1гар100 = (year - 1800] / 100; 
29 ілс leapd00 = (year - 1600) / 400 
30 return leap4 - leapl00 + leapi00; 
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DayDateFactory.java (Final) 


package org, jfree.date; 


1 

3 public abstract class DayDateFactory ( 

4 private static DayDateFactory factory = new SpreadsheetDateFactory(); 
5 

é 

H 


public static void setInstance(DayDateFactory factory) f 
DayDateFactory.factory = factory; 


3 protected abstract DayDate makeDatetint ordinal); 
10 protected abstract DayDate _makeDate(int day, Month month, int year); 
11 protected abstract DayDate _makeDate(int day, int month, int year): 
12 protected abstract DayDate makeDate(java.util. Date date); 

13 protected abstract int _getMinimumYear(); 

14 protected abstract int | getMaximumYear(); 


15 

16 public static DayDate makeDate(int ordinal) ( 

7 return factory. mkeDateiordinal]; 

18 } 

19 

20 public static DayDate makeDate(int day, Month month, int year) { 
21 return factory. лакеПаге(баү, month, year]: 


24 public static DayDate makeDate(int day, int month, int year) { 
25 return factory. makeDateiday, month, year); 


21 } 


28 public static DayDate maxeDate|java.util.Date datei ! 


29 return factory. _makeDate [date] ; 

3 1 

22 public static int getMinimunvear(} ( 
33 return factory. getMinimunYear |) ; 
M } 

3€ public static int getMaximumYear() ( 
27 return factory. getMaximun"ear () ; 
3 1 
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Listagem B-15 
SpreadsheetDateFactory. java (Final) 


package org. jfree.dare; 


import java.util.*: 


public class SpreadsheetDateFactory extends DayDatePactory { 
public DayDate makeDatelint ordinal) { 
return new SpresdshesiDate (ordinal) ; 


public DayDate makeDatetint day, Month month, int year) ( 
return new SpreadsheetDate (day, month, year! 


public DayDate _makeDate(int day, int month, ant year) | 
rerum new Ѕргеадѕћееграге day, month, year); 
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Listagem B-15 
SpreadsheetDateFactory.java (Final) 


18 
19 
20 


21 
4 


public DayDate _makeDate\Date date) { 
final GregorianCalendar calendar = new GregorianCalendar ( 
calendar. set Time (date) ; 
return new SpreadsheetDace( 
calendar .get (Calendar.DATE!, 
Month. £ronInt (calendar .get (Calendar .MONTH) + 1), 
calendar .cet (Calendar.YEAR)); 


protected int getMinimusfeari] ( 


return SpreadsheetDate.MINIMUM, YEAR SUPPORTED; 


protected inr getMaximumfear() | 
return, Spreadsheet Date.MAXIMUM YEAR. SUPPORTEI 
] 


Listagem B-16 
SpreadsheetDate.java (Final) 


81 
82 
БИ 


: а free general purpose class 


) Copyright 2000-2005, by Object Refinery Limited and Contributors. 


package org. jfree.date; 
import static org.jfree.date.Month. FEBRUARY; 


import java.util.*; 


* Represents a date using an integer, im a similar fashion to the 


implementation in Microsoft Excel. The range of dates supported 
ап-1900 to 31-Dec-9399, 
<р/> 
Бе aware that there is a deliberate bug in Excel that recognises the year 
1900 as a leap year when in fact it is nor a leap year, You can find more 
information on the Microsoft website in article 0181270: 
qu» 
http://support microsoft .com/support /'kb/artícles/Q181/3/70.asp 
xpi 


Excel uses the convention that l-Jan-1900 = 
convention 1-Jan-1800 
The result is that the d: 


This class uses the 


his class will be different to the 
Excel figure for January and February 1300...but then Excel adds in an extra 
day (29-Feb-1909 which does not actually exist!) and from that point forward 
the day numbers will match, 


Bauthor David Gilbert 


public class SpreadsheetDate extends DayDate | 
public static final int EARLIEST DATE ORDINAL 
public static final int LATEST DATE ORDINAL = 
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SpreadsheetDate.java (Final) 

33 public static final int LATEST DATE ORDINAL = 2958465; // 12/31/9999 

84 public static final int MINIMUM YEAR SUPPORTED = 1900; 


a5 


public static final int MAXIMUM YEAR SUPPORTED = 9º 

static final int[] AGGREGATE DAYS TO END OF PRECEDING MONTH = 
(0, 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365); 

static final int} LEAP YEAR AGOREGATE DAYS TO END OF PRECEDING MONTH = 
(0, 0, 31, 60, 91, 121, 152, 192, 213, 244, 274, 305, 335, 366); 


private int ordinalDay: 
private int day; 
private Month month; 
private int year; 


public SpreadsheerDatetint day, Month month, int year) ( 
if (year < MINIMUM YER SUPPORTED || year > MAXIMUM YEAR SUPPORTED) 
throw new IllegalArgunent Exception ( 
“The 'year' argument must be in range * + 
MINIMUM YEAR SUPPORTED + * to * + MAXIMUM YEAR SUPPORTED + *. 
if (day < 1 || day > DateUtil.lastDayOfMonth(month, yeari) 
throw new TllegalArgumentException!*Invalid ‘day’ argument, "}: 


this.day = day; 


ordinalDay = calcOrdinal(day, month, year); 


public SpreadsheetDate(int day, int month, int year) ( 
this(day, Month frowInt (month), year); 


public SpreadsheetDate(int serial) ( 

af (serial < EARLIEST DATE ORDINAL |! serial > LATEST DATE ORDINAL) 
throw new IllegalArgumentzxception| 

*SpreadsheetDate: Serial must be in range 2 to 2958465. 


ordinalDay = serial; 
calcDayMonthYear) ; 
} 


public int getOrdinalDay() { 
return ordinalDay 


lic int getYear!) { 


return year; 


public Month getMonth() ( 
return month; 
) 


public int getDayOfMontkl) i 
return day; 
H 


protected Day getDayOfWeekForOrdinalzero() (return Day.SATURDAY;) 


public boolean equals(Object object) ( 
if (!(object instanceof DayDatel] 
return false; 
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Listagem B-16 (continuação) 
SpreadsheetDate.java (Final) 


144 

145 Оауабе date = (DayDate) objec 
146 return date.getOrdinalDay() 
) 


public int hashCode() { 
return getordinalDay(); 
1 


public int compareTo(Object other] { 
return daysSince(iDayDare) other}: 
) 


private int calcordinal int day, Month month. int year! ( 
int leapDaysForYear = DateUtil.leapYearCount (year - 1); 
int daysUpToYear = (year - MINIMUM YEAR SUPPORTED) * 365 + leapDaysForYear; 
int daysUpToMonth = AGGREGATE. DAYS. TO. END OF. PRECEDING, MONTH (month. toTnt () | ; 
if (DateUtil.isLeapear(year) && month.toIrti) > FEBRÜARK.toInt(]| 
daysUpToMonth++ 
int daysInMonth = 
irn daysUpToYear + daysUpToMonth + daysinMonth + FARLIEST DATE ORDINAL; 


private void calcDayMonthYear() ( 
int days = ordinalDay - EARLIEST DATE, ORDINAL; 
int overestimatedYear = MINIMUM YEAR SUPPORTED + days | 365; 
int nonleapdays = days - DateUtll.leapYearCount (overestimatedYear!; 
int underestimaredYear = MINIMUM YEAR SUPPORTED + nonleapdays ^ 365; 


linalofYeari; 
'sBeforeThisMonth(month.cctat (]] ; 


ing fordinalDa; 
rstOrdinalOfYear - да) 


) 


anOrdinal, int firstOrdinalOfYear] { 
'OrdinalofYear; 


private Month huntForMonthContaining(i: 
int daysintoThisYear = anOrdinal - f 
int aMonth = 1; 
while (daysBeforeThisMonthlaMonth) < daysintoThisvear) 
aMonth++; 


return Month. fronInt iaMonth 


wate int daysBeforeThisMonth!int aMonth! { 
if (Datelci 1. isLeapyear year) ) 
return LEAP YEAR AGGREGATE DAYS TO END OF PRECEDING MONTH[aMonth] - 1; 
else 
return AGGREGATE DAYS TO END OF PRECEDING MONTH[aMonth] - 1; 
| 


private int huntForYearContaining(int anOrdinalDay, int startingYear] i 
int aYear = startingYear; 
while (firstOrdinalOfYear(aYear! <= anôrdinalhay) 
аїгаг++; 


return аїваг - 
) 


private int firstOrdinalOfYear (int year) ( 
return calcOrdinal(1, Month. JANUARY, year): 
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Listagem B-16 (continuacáo) 
SpreadsheetDate.java (Final) 


reateinstance(Date date) ! 


public static DayDate 
dar = new GregorianCalendar(); 


GregorianCalendar cal 
calendar. setTime (date 
return new SpreadsheerDate [calendar .ger (Calen 
Month. fromint 
calendar. get (Calendar. YEAR) | ; 


ndar.MONTH) + 11, 


Apêndice C 


Referência Cruzada das Heurísticas 


Referência cruzada de “odores” e heurísticas. Podem-se excluir todas as outras. 


.. 16-276, 16-279, 17-292 
16-279, 16-285, 16-295, 17-292 


Сз 16-283, 16-285, 16-288, 17-293 
C4 17-293 
cs 17-293 
El 17-294 
E2 

Fl 

F2 

ЕЗ 

F4. 

Gl. 

G2. 16-273, 16-274, 17-296 
G3. 16-274, 17-296 
G4. 9-31, 16-279, 16-286, 16-291, 17-297 


31, 16-279, 16-286, 16-291, 16-296, 17-297 
284, 16-289, 16-293,16-294, 16-296, 17-299 
.16-281, 16-283, 17-300 
16-283, 17-301 
„ 16-287, 17-302 
5-86, 15-264, 16- 276, 16-284, 17-302 
...15-264, 16-284, 16-288, 16-292, 17-302 
6-284, 16-285, 16-286, 16-287, 16-288, 16-295, 17-303 
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6-286, 16-288, 17-303 
288, 16-292, 17-304 
16-288, 17-305 
16-289, 17-306 
6-289, 17-307, 17-312 
6-289, 16-290, 16-291, 17-308 
6-291, 16-292, 17-309 
16-290. 17-309 
16-291. 17-310 
16-294, 17-322 
239, 16-295, 17-313 
16-296, 17-313 
16-296, 17-314 


15-264, 17-318 
15-265, 17-319 
15-265, 15-266, 17-320 
1-40, 6-106, 17-321 
5-90, 17-323 
6-103, 17-324 
16-276, 17-325 
-278, 16-285, 17-326 
16-283, 16-285, 17-327 
15-264, 16-277, 16-279, 16-282, 16-287, 16-288, 
16-289, 16-290, 16-294, 16-296, 17-328 
16-277, 17-330 
6-284, 16-288, 17-331 
5-263, 16-291, 17-332 
2-26, 14-221, 15-262, 17-332 
15-261, 17-333 
15-263, 17-333 
6-273, 16-274, 17-334 
16-273, 17-334 
16-274. 17-334 
..17-334 
-275, 17-335 
16-275, 17-335 
16-275, 17-335 
16-275, 17-335 
.. 17-336 


Epílogo 


Em 2005, durante a conferência sobre о Agile em Denver, EUA, Elisabeth Hedricksonl me 
ofereceu uma fitinha verde de punho parecida àquela que Lance Armstrong tornou tão popular. 
Nela estava escrito “Obcecado por testes”. Com satisfação, amarrei-a em meu punho c a usei 
com orgulho. Desde que Kent Beck me ensinou, em 1999, sobre o TDD, fiquei, de fato, obcecado 
pelo desenvolvimento dirigido a testes. 

Porém, algo estranho aconteceu. Descobri que eu não poderia retirar minha fitinha do punho. 
Não por que ela estivesse presa a ele, mas por estar moralmente presa. À fita fazia uma afirmação 
evidente sobre minha ética profissional. Era visível meu comprometimento em criar o melhor 
código que eu pudesse. Tirá-la seria como trair tal ética e comprometimento. 

Devido a isso, ela ainda está em meu punho. Quando escrevo um código, a vejo através de 
minha visão periférica. Ela é um lembrete constante da promessa que fiz a mim mesmo para criar 
códigos limpos. 
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Por outro lado, uma tríade que não é nem tão perigosa assim é a assertEquals(1.0, 
amount, .001). Embora ainda seja preciso lê-la duas vezes, é uma que vale a pena. Sempre é 
bom uma dica de que a igualdade de valores do tipo ponto flutuante é relativa. 


Objetos como Parâmetros 


Quando uma função parece precisar de mais de dois o três parâmetros, é provável que alguns 
deles podem ser colocados em uma classe própria. Considere, por exemplo. a diferença entre as 
duas declarações seguintes: 


Circie makeCircle(double x, double v, double radius); 
Circle makeCircle(Point center, double radius); 


Reduzir o número de parâmetros através da criação de objetos a partir deles pode parecer 
uma trapaça, mas não é. Quando grupos de variáveis são passados juntos. como x e y no exemplo 
acima, é mais provável que sejam parte de um conceito que mereça um nome só para ele. 


Listas como Parâmetros 


Às vezes, queremos passar um número variável de parâmetros para uma função. Considere, por 
exemplo, o método String. format: 


String.format("$s worked %.2f hours.", name, hours); 


Se os parámetros variáveis forem todos tratados da mesma forma, como no exemplo acima, 
então eles serão equivalentes a um único parâmetro do tipo lista. Devido a isso, String.format é 
realmente díade. Na verdade, sua declaração, como mostra abaixo, é explicitamente díade. 


public String format (String format, Object... args) 


Portanto, todas as mesmas regras são aplicáveis. As funções que recebem argumentos variáveis 
podem ser ménades, díades ou mesmo triades. Mas seria um erro passar mais parâmetros do que isso. 


void monad(Integer... args); 
void dyad(String name, Integer... args); 


void triad(String name, int count, Integer... args); 


Verbos e Palavras-Chave 


+ 
Escolher bons nomes para funções pode ir desde explicar o propósito da função à ordem e a 
finalidade dos parâmetros. No caso de uma mônade, a função e o parâmetro devem formar um 
belo par verbo/substantivo. Por exemplo, escrever (nome) é bastante claro. Seja o que for esse 
“nome”, ele será “escrito”. Um nome ainda melhor seria “escreverCampo (nome), que nos diz 
que “nome” é um “campo”. 

Este último é um exemplo do formato palavra-chave do nome de uma função. Ao usar este 


